I tested notifyCommit messages sent to the git plugin in Jenkins – what happens when you commit several different branches in the same repo and rely on the git plugin to catch and schedule. The results were – odd. Some branches committed never made it. The limit for certainty seems to be the first commit, and then a second in the queue. After that the build might be queued, but it won’t necessarily build against the commit branch.
- Commit sequence (branches)
- rc
- test-cicddiscover-branch
- test-yetanotherbranch
- test-thirdman
- test-thirdman
- test-yetanotherbranch
- rc
- test-fifthbranchtotest
- test-fifthbranchtotest
- test-cicddiscover-branch
- test-yetanotherbranch
- rc
- test-autobuild
- Then, the jobs build against…
- #1 rc
- #2 test-thirdman
- #3 test-thirdman (failed)
- $4 test-yetanotherbranch (failed, I killed it)
- #5 rc
- #6 test-fifithbranchtotest
- #7 test-fifthbranchtotest
- #8 test-cicddiscover-branch
- #9 test-yetanotherbranch
- #10 rc
- #11 test-autobuild (failed, never set up to build properly)
- #12 test-autobuild (also failed)
- and there is a #13 – undetermined – which can’t start because the subnet jenkins is on does not have any more IPs and can’t start up a slave…
With just the notifyCommit message, commits to test-cicddiscover-branch and test-yetanotherbranch disappeared. Enabling the SCM polling seems to allow Jenkins to go and find the missing builds. And once that was enabled (about Build #4) the sequence started to not necesarily normalize but at least build once against every branch committed to. Better. Seems like SCM polling at some interval must be enabled to make sure you catch all builds. I think this is good enough to work with.
This doesn’t relate to the CicdDiscover plugin. These builds are AFTER the job has been created and that new plugin is never touched – this is SCM and git plugins, and Jenkins scheduling internals. It came up when I started testing for coincident commits, the first to the CicdDiscover, which created the job, and the second to the same repo now created but to a different branch. That worked. But once I started committing multiples to the same repo, I got this behavior – which needed a resolution.
—doug