Recently I investigated some odd build behavior on our farm which seemed to be related to this defect I reported, however the behavior I am now seeing looks to be slightly different than it was with the previous versions of Jenkins and this plugin that we were using before. Now, the behavior appears to be such that the BuildCause is only looking at one of potentially several causes and the conditional build step plugin is then just picking the first of those to use within it's condition checks. For example, here is a use case I just reproduced:
- Job A gets triggered by an SCM change, so BuildCause is SCMTRIGGER
- upon completion, Job A triggers Job B as a post-build step
- Job B then launches which has a conditional build step that should run when the BuildCause is of type SCMTrigger however the conditional action does not run because the BuildCause is actually reported as UPSTREAMTRIGGER
Further, when considering more complex scenarios the plot seems to thicken. For example, suppose someone commit's a change to "Project A" (built by Job A) and "Project B" (built by Job B) at the same time. The sequence appears to go something like this:
- Job A gets triggered by the SCM change, and BuildCause is set to SCMTRIGGER
- upon completion, Job A triggers Job B as a post-build step
- Job B then launches as a result of Job A's trigger, picking up the SCM changes just committed as well, but the conditional build action still refuses to run because the BuildCause is still reported as UPSTREAMTRIGGER
Closer examination of some of our production builds revealed that there are several BUILD_CAUSE environment variables available to each build. Two of the most interesting ones appear to be BUILD_CAUSE and ROOT_BUILD_CAUSE. Based on my own naive interpretation of their values, it appears as though the former tells us one (from potentially several) causes for the current job being run while the latter seems to tell us what the build cause was for the lowest level job in the dependency tree that lead to this build.
So, in the case of example #1 above, BUILD_CAUSE for job B is UPSTREAMTRIGGER while the ROOT_BUILD_CAUSE is SCMTRIGGER. Interestingly, in example #2 the same results seem to be consistent with example #1. It is almost like, even though Job B has more than one trigger for the current build, the system is only reporting one of them under BUILD_CAUSE, so in this case UPSTREAMTRIGGER is reported and SCMTRIGGER is simply ignored.
Not sure what part of the Jenkins system sets that BUILD_CAUSE environment variable, but it would appear that part may be to blame for this odd behavior.
Feel free to reassign this defect to a more relevant Jenkins component / category if this new information helps further isolate the problem.
assigning this also to the run-condition plugin, as the conditional buildstep plugin itself does not make any decisions, but relies on the run-condition plugin.