Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-18134

SCMTrigger condition includes upstream builds

      Based on my ad-hoc tests it appears as though the conditional build step plugin will look to upstream jobs and use the trigger settings from those configurations when deciding whether to trigger a downstream job. This should not happen - or at the very least be optional.

      Use Case

      1. Job A is triggered by a SCM trigger
      2. once complete, job A triggers Job B as a post-build step
      3. Job B has a conditional build step that is set to only run on an SCMTrigger. Given that the trigger for the current execution was the successful completion of a previous job I would expect this task to not get executed. However, apparently it does get executed in this situation because the upstream Job A had a code change and the SCMTrigger condition looks to all upstream jobs for their statuses rather than just looking at the current job.

      From what I can tell there is no way to force this condition to ignore upstream build triggers and just look at the trigger for the current job. So unless I'm missing something I would suggest that this plugin should at least add the option to ignore upstream jobs, if not remove said logic so it only ever looks at the current job.

      I am using Jenkins v1.509.1 (LTS edition), with v1.2.1 of the conditional build step plugin.

          [JENKINS-18134] SCMTrigger condition includes upstream builds

          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.

          Dominik Bartholdi added a comment - 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.

          I see there has been no activity on this bug report for several years. I'm wondering if anyone is planning on looking into this?

          NOTE: We have since upgraded to Jenkins LTS 1.596.3 and plugin v1.3.3 (the latest edition) and this appears to still be an issue.

          Kevin Phillips added a comment - I see there has been no activity on this bug report for several years. I'm wondering if anyone is planning on looking into this? NOTE: We have since upgraded to Jenkins LTS 1.596.3 and plugin v1.3.3 (the latest edition) and this appears to still be an issue.

          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:

          1. Job A gets triggered by an SCM change, so BuildCause is SCMTRIGGER
          2. upon completion, Job A triggers Job B as a post-build step
          3. 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:

          1. Job A gets triggered by the SCM change, and BuildCause is set to SCMTRIGGER
          2. upon completion, Job A triggers Job B as a post-build step
          3. 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.

          Kevin Phillips added a comment - 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.

          Kevin Phillips added a comment - - edited

          I probably should clarify that the ROOT_BUILD_CAUSE does appear to look at the build cause of the very first job in a sequence to see what initiated subsequent triggers. So, consider the following example:

          1. Job A starts because of an SCM change, and has it's BUILD_CAUSE set to SCMTRIGGER
          2. Job A triggers Job B in a post build step
          3. Job B then runs and triggers Job C as a post build step
          4. Job C then runs. It's BUILD_CAUSE will be UPSTREAMTRIGGER because Job B is what told it to run, but the ROOT_BUILD_CAUSE appears to be set to SCMTRIGGER because Job A was the first to run in the sequence and it's cause was SCMTRIGGER.

          Similarly, if Job C simultaneously picks up SCM changes at the same time Job B triggers it, it's BUILD_CAUSE will still be set to UPSTREAMTRIGGER. The SCM changes that were picked up basically get lost in the mix and they don't appear to be reported correctly. This, I think, is essentially the problem I'm trying to describe here.

          In such cases, I would expect the BUILD_CAUSE to report all of the events that may have lead to the build being triggered, thus allowing plugins like the condition build to look through the list and select the one(s) they are interested in.

          In fact, it would appear that the conditional build plugin already supports processing multiple triggers because the conditions you can provide expose an option to only run when that build cause is "exclusive" (ie: only that one build cause and no others). The only way such an option makes sense is if the plugin supports detecting and processing builds that run as a result of multiple triggers..

          Kevin Phillips added a comment - - edited I probably should clarify that the ROOT_BUILD_CAUSE does appear to look at the build cause of the very first job in a sequence to see what initiated subsequent triggers. So, consider the following example: Job A starts because of an SCM change, and has it's BUILD_CAUSE set to SCMTRIGGER Job A triggers Job B in a post build step Job B then runs and triggers Job C as a post build step Job C then runs. It's BUILD_CAUSE will be UPSTREAMTRIGGER because Job B is what told it to run, but the ROOT_BUILD_CAUSE appears to be set to SCMTRIGGER because Job A was the first to run in the sequence and it's cause was SCMTRIGGER. Similarly, if Job C simultaneously picks up SCM changes at the same time Job B triggers it, it's BUILD_CAUSE will still be set to UPSTREAMTRIGGER. The SCM changes that were picked up basically get lost in the mix and they don't appear to be reported correctly. This, I think, is essentially the problem I'm trying to describe here. In such cases, I would expect the BUILD_CAUSE to report all of the events that may have lead to the build being triggered, thus allowing plugins like the condition build to look through the list and select the one(s) they are interested in. In fact, it would appear that the conditional build plugin already supports processing multiple triggers because the conditions you can provide expose an option to only run when that build cause is "exclusive" (ie: only that one build cause and no others). The only way such an option makes sense is if the plugin supports detecting and processing builds that run as a result of multiple triggers..

            bap bap
            leedega Kevin Phillips
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: