jenkins一次构建两次触发job问题

具体内容详见： https://issues.jenkins-ci.org/browse/JENKINS-21464?focusedCommentId=250183&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-250183

jenkins中构建里面的内容：Multiple candidate revisions

I also observed similar behavior. When 'Branch Specifier' was not unique, then checkout actually triggered another build of the same job.

This was strange, because the job didn't have Poll SCM Build Trigger checked. Actually this job had none of the Build Trigger mechanisms checked and was intended to be scheduled only manually.

The first build was executed manually with Branch Specifier = branch123 and log contained:

 > git rev-parse branch123^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/branch123^{commit} # timeout=10
Multiple candidate revisions
Scheduling another build to catch up with My_Build_Job_Name

At that point a new unwanted build of this job was scheduled and waited in the Build Queue. When it started, the log contained:

Started by an SCM change
Building on master

The initial problem was non-unique Branch Specifier. I will fix it by using the longer remote ref refs/remotes/origin/branch123.

Mark Waite Could you consider changing the plugin to fail instead of triggering a new build in case non-unique revision is required to be checked out? At least in case when job does not allow Poll SCM Build Trigger.

---

What was the job for and how this issue happened?

The job uses Jenkins job SCM Git to checkout a branch (say branch123) with Clean before checkout. Then in Execute shell build step it modifies some files in the checkout (pom.xmls), commits, tags (as tag123-rc1) and pushes. The local branch123 HEAD points to the same commit as tag123-rc1. So far so good.

Then developers push more changes into branch123 and we want to release as tag123-rc2. So we run our job again. Git-plugin does cleanup on the repository in the job workspace, but this leaves the local branch123 intact, so it still points to the same revision as tag123-rc1. (so other viable solution would be to wipe workspace between builds)

Plugin then fetches refs from remote and refs/remotes/origin/branch123 now points to the new commits made by developers. Git-plugin compares revision of both references that contain substring branch123. Since the remote branch moved, both refs now point to different revisions. Git-plugin reacts to this with 'Multiple candidate revisions' message and triggers a new build.

In case both refs point to the same revision (no changes were made on the branch between two builds), then Git-plugin checks out the single revision and no build is triggered.

 > git config remote.origin.url ssh://XXX.git # timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
 > git submodule foreach --recursive git reset --hard # timeout=10
 > git submodule foreach --recursive git clean -fdx # timeout=10
Fetching upstream changes from ssh://XXX.git
 > git --version # timeout=10
using GIT_SSH to set credentials XXX
 > git fetch --tags --progress ssh://XXX.git +refs/heads/*:refs/remotes/origin/*
 > git rev-parse branch123^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/branch123^{commit} # timeout=10
Multiple candidate revisions
Scheduling another build to catch up with My_Build_Job_Name