-
Bug
-
Resolution: Duplicate
-
Critical
-
None
-
Centos 6.4, Jenkins 1.610 / 1.611
Recently upgraded to Jenkins 1.610. Nothing that 2 jobs were running that not supposed to run at the same time as I have "Block build when upstream project is building" and "Block build when downstream project is building". When to first job in the stream and verified configs set. When I went to the first downstream job, and look in the "Advanced Project Options" section, there's no "Advanced" button to click to look at settings. What's weird is I know there are settings as I "Use custom workspace" and can see (when I try to run the job) that this setting is still in effect. Upgraded to 1.611 to see if fixed and same issues exists. I had also recently installed the "Build Blocker" plug-in and wondered if that had any interactions. But after uninstalling and restarting Jenkins, still have the same issues. As I can't have to coordinate some jobs, this is a blocker.
I found the Advanced button, it was hidden.
But the issue still remains that Jenkins is not handling starting jobs correctly in an upstream/downstream situation.
In abstract, here's my setup job A is dependent on section A (using SVN).
If A runs, it will spawn job B. Job B can also run if section B (using SVN) changes. If job B runs, it spawns job C (which has no SVN dependencies).
So here's the scenario changes comes into to SVN B, spawn job B, it completes and spawn job C. While job C is running, another changes comes into SVN B. That queues job B but won't run as job C is running. Still while C is running, a SVN changes comes into area A. That queues job A and doesn't run as job C is still running. This is all as expected.
Now job C finishes. Jobs A and B are queued and neither one starts (and I caught this when both had been in queue for over 4 hours). If I manually try to start either, nothing happens and both remained queued.
The only solution was to kill one job (in my case I killed B, since I knew after A ran it would run B anyways – and get B's SVN changes). Immediately upon killing B in the queued state, A started running. (and when it finished, B ran, finished, and ran C).
So it looks to me like there's a bug in Jenkins 1.611 (and was in 1.610) – where if 2 jobs are queued that are in a upstream/downstream relationship and both are configured to not run if upstream/downstream is running, then it will start neither.
FYI, I was on an old version of Jenkins (1.530) and this functionality was working just fine. I upgraded to 1.610 for other features and then later discovered this broke.
Also, I have uninstalled Build Blocker plugin (and restarted Jenkins) and my above ABC scenario still exists. So I don't think Build Blocker plugin has anything to do with the issue, just a bug in Jenkins.