Issue
A job that should only have been triggered once is seen to have run multiple times. This issue can be seen on jobs that are configured to use an SCM repository.
This is caused by similar names existing in multiple branches in the scm. On startup on the build you will see something like this:
> /bin/git rev-parse refs/remotes/origin/test-build-version-tag^{commit} # timeout=10
> /bin/git rev-parse refs/remotes/origin/origin/test-build-version-tag^{commit} # timeout=10
This will result in a second build running. You will see the first build being triggered normally:
Started by user admin
and then the second build will be triggered like this:
Started by upstream project "releaseTeam/testJobs/testingDeploy" build number 10
Environment
-
CloudBees CI (CloudBees Core) on modern cloud platforms - Managed controller
-
CloudBees CI (CloudBees Core) on modern cloud platforms - Operations Center
-
CloudBees CI (CloudBees Core) on traditional platforms - Client controller
-
CloudBees CI (CloudBees Core) on traditional platforms - Operations Center
-
CloudBees Jenkins Enterprise
-
CloudBees Jenkins Enterprise - Managed controller
-
CloudBees Jenkins Enterprise - Operations center
Resolution
This issue results from a job being configured with an ambiguous BRANCH_NAME.
For example, if there is a build configured with the BRANCH_NAME of release, but there are two branches in the repository:
-
refs/remotes/origin/release
-
refs/remotes/origin/origin/release
You will see this issue here.
To resolve this, you’ll want to ensure that there is no ambiguity in the BRANCH_NAME that is configured.
For the example here, using the BRANCH_NAME refs/remotes/origin/origin/release will ensure that only one branch is found and thus only one build gets run.
Tested product/plugin versions
-
CloudBees Core on Modern Platforms up to v2.164.3.2