I started off from scratch with our CicdDiscover Jenkins plugin. I created and kicked off a job in Jenkins by committing to branch “test-cicddiscover-branch”. This as expected created the job. It then started building – not the test-cicddiscover-branch change, but an earlier change to origin/rc.
I went ahead and committed another two changes, to branch “test-yetanotherbranch” and to branch “test-thirdman”. So we have four changes to be queued – the queue still shows only the job building, which is origin/rc, and a second undefined job, #2.
This was of concern – because what happens to simultaneous commits to the same repo and therefore the same job in Jenkins that are to be triggered by a notifyCommit message. Are the extras lost? They don’t show up in the queue…
I already know that separate repos – commits to different repos – therefore different jobs – show up directly in the build queue. The Jenkins UI seems to behave differently with multiple builds to the same repo. I would have expected them all to show up – but they don’t.
Once that origin/rc job was completed, the #2 build xcomes into the queue and is build – and it’s not origin/test-cicddiscover-branch. It’s the LAST commit – origin/test-thirdman…
So – we have the queued notifyCommit jobs to the same repo not showing up until the active job completes, and we have the last commit coming off the queue first – LAST ON FIRST OFF.
The next job, #3, then should be not test-cicddiscover-branch, but rather origin/test-yetanotherbranch.
Waiting… And then it catches and rebuilds the origin/test-thirdman again… Wait, what?
- The queue should be at this point
- test-yetanotherbranch
- test-cicddiscover-branch
So why is it catching the same change and comparing it against origin/rc, instead of seeing the change to the other branches? This looks like maybe the git-plugin registers the notifyCommit but doesn’t specify it? I don’t think that’s right.
- adding more commits then waiting… So we have in reverse order
- test-fifthbranchtotest (brand new branch)
- test-cicddiscover-branch
- rc
- test-yetanotherbranch
- test-cicddiscover-branch
I enabled SCM Polling in 10 minute intervals to see if that catches the rest of the changes… And instead of mixing this up further I’m waiting.
update 20180919
It turns out this continued to be an issue with Jenkins – there are internal assumptions of state. Jenkins assumes it is the only one, and then it has been up for quite some time. In looking deeper at the git plugin and SCM coding, if there is no history to guide and Jenkins is left to determine what to build when the job is first triggered, it will grab the latest commit to the alphabetically first branch in the list. Yes, really. This deserves another article… I added to the CICD Discover plugin to have it determine and enforce building the latest commit at the time the notifyCommit is transmitted, and then added Jenkins global shared library functions to bypass “checkout scm” and do the right thing regardless of state.
—doug