-
Bug
-
Resolution: Fixed
-
Major
-
Branch API 1.0
cc jglick
If you have multiple SCMSource s on a multibranch project, for example two Git repos that both have a "master" branch (or any branch name for that matter), and one source does not exclude the conflict, then the MultiBranchProject attempts to create the branch again for each source.
Because the project for that branch already exists and has built, you end up with a bunch of dead executors because builds for these new projects get triggered.
Started Setting origin to /foo/bar/project1.git Fetching origin... Pruning stale remotes... Getting remote branches... Checking branch stable Checking branch feat/tracking-data Checking branch master Scheduling build for branch: master Checking branch development Scheduling build for branch: development Checking branch feat/test Done. Setting origin to /foo/bar/project2.git Fetching origin... Pruning stale remotes... Getting remote branches... Checking branch master Scheduling build for branch: master Checking branch development Scheduling build for branch: development Done. Finished: SUCCESS
Thread has died java.lang.IllegalStateException: /Users/mjdetullio/jenkins/jobs/freestyle-multi/branches/master/builds/1 already existed; will not overwrite with freestyle-multi/master #1 at hudson.model.RunMap.put(RunMap.java:188) at jenkins.model.lazy.LazyBuildMixIn.newBuild(LazyBuildMixIn.java:176) at hudson.model.AbstractProject.newBuild(AbstractProject.java:1019) at hudson.model.AbstractProject.createExecutable(AbstractProject.java:1210) at hudson.model.AbstractProject.createExecutable(AbstractProject.java:145) at hudson.model.Executor$1.call(Executor.java:364) at hudson.model.Executor$1.call(Executor.java:346) at hudson.model.Queue._withLock(Queue.java:1405) at hudson.model.Queue.withLock(Queue.java:1270) at hudson.model.Executor.run(Executor.java:346)
The obvious solution is to make sure your includes/excludes are properly defined. However, if users do not have a clearly defined naming convention and wish to pull from multiple SCMSource s, then there is nothing to prevent them from entering an erroneous state where multiple projects for a branch exist in memory trying to share the same config location on the filesystem. This in itself is a problem that is easily encountered, even if the use case of having two jobs for a branch with the same name is not supported.
- links to
[JENKINS-32179] Branch indexing always attempts to create a new project for conflicting branch names from multiple sources
Code changed in jenkins
User: Jesse Glick
Path:
src/main/java/com/cloudbees/hudson/plugins/folder/computed/ComputedFolder.java
src/test/java/com/cloudbees/hudson/plugins/folder/computed/ComputedFolderTest.java
http://jenkins-ci.org/commit/cloudbees-folder-plugin/30f744250762bf9472cd269a0bef4a597203be01
Log:
[FIXED JENKINS-32179] Logic error when computeChildren suggested the same child name twice during recomputation.
Code changed in jenkins
User: Jesse Glick
Path:
src/main/java/com/cloudbees/hudson/plugins/folder/computed/ComputedFolder.java
src/test/java/com/cloudbees/hudson/plugins/folder/computed/ComputedFolderTest.java
http://jenkins-ci.org/commit/cloudbees-folder-plugin/5f239712601807f3f1eb6f573a8fa550261978a7
Log:
Merge pull request #42 from jglick/duplicate-children-JENKINS-32179
JENKINS-32179 Logic error when computeChildren suggested the same child name twice during recomputation
Compare: https://github.com/jenkinsci/cloudbees-folder-plugin/compare/cd19df833004...5f2397126018
Code changed in jenkins
User: Jesse Glick
Path:
multibranch/pom.xml
multibranch/src/test/java/org/jenkinsci/plugins/workflow/multibranch/WorkflowMultiBranchProjectTest.java
http://jenkins-ci.org/commit/workflow-plugin/8739b2321b57cbb638e29ff3941628d11f3057cb
Log:
JENKINS-32179 Integration test.
Code changed in jenkins
User: Jesse Glick
Path:
multibranch/src/test/java/org/jenkinsci/plugins/workflow/multibranch/WorkflowMultiBranchProjectTest.java
http://jenkins-ci.org/commit/workflow-plugin/5b4c683a801a0685e9d8e3af69c3be096ded6984
Log:
Merge pull request #363 from jglick/duplicate-children-JENKINS-32179
JENKINS-32179 Integration test
Compare: https://github.com/jenkinsci/workflow-plugin/compare/e161fcfbecac...5b4c683a801a
Code changed in jenkins
User: Jesse Glick
Path:
multibranch/pom.xml
multibranch/src/test/java/org/jenkinsci/plugins/workflow/multibranch/WorkflowMultiBranchProjectTest.java
http://jenkins-ci.org/commit/workflow-multibranch-plugin/596a2cfdfc5cd6353281a59988d119b96b6e9aaa
Log:
JENKINS-32179 Integration test.
Originally-Committed-As: 8739b2321b57cbb638e29ff3941628d11f3057cb
Code changed in jenkins
User: Jesse Glick
Path:
src/test/java/org/jenkinsci/plugins/workflow/multibranch/WorkflowMultiBranchProjectTest.java
http://jenkins-ci.org/commit/workflow-multibranch-plugin/8773373ac64d669333080573724c4c8ffe186ea3
Log:
JENKINS-32179 Can enable test now.
Code changed in jenkins
User: Jesse Glick
Path:
src/test/java/org/jenkinsci/plugins/workflow/multibranch/WorkflowMultiBranchProjectTest.java
http://jenkins-ci.org/commit/workflow-multibranch-plugin/4880dc4a62991817439f1f8e07bb4cc42c4dec27
Log:
Merge pull request #40 from jglick/test-JENKINS-32179
JENKINS-32179 Can enable test now
Compare: https://github.com/jenkinsci/workflow-multibranch-plugin/compare/413439756ded...4880dc4a6299
The intent was for the first one to “win”. The user should not be obliged to set up exclusions to handle this case.