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

Removing ReverseBuildTrigger from Pipeline Job Does Not Take Effect

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • core, pipeline
    • Jenkins 2.440.1 with OpenJDK Runtime Environment, 11.0.22+7-LTS on CentOS Linux release 7.9.2009 (Core)

      Pipeline Job B was configured to trigger every time upstream Pipeline Job A completes successfully. After this configuration was removed, new successful runs of Pipeline Job A still triggered Pipeline Job B.

      Initial Job B config.xml:

      <org.jenkinsci.plugins.workflow.job.properties.PipelineTriggersJobProperty>
          <triggers>
              <jenkins.triggers.ReverseBuildTrigger>
                  <spec/>
                  <threshold>
                      <color>BLUE</color>
                      <completeBuild>true</completeBuild>
                      <name>SUCCESS</name>
                      <ordinal>0</ordinal>
                  </threshold>
                  <upstreamProjects>UpstreamPipelineJobA</upstreamProjects>
              </jenkins.triggers.ReverseBuildTrigger>
          </triggers>
      </org.jenkinsci.plugins.workflow.job.properties.PipelineTriggersJobProperty> 

      Making further updates to the configuration for Pipeline Job B still did stop the trigger from occurring. Using the groovy scripting console (<JENKINS_URL>/script) for both Job A and B, getting the WorkflowJob objects and checking getTriggers(), getTriggersJobProperty()?.getAllTriggerActions() and getTriggersJobProperty()?.getTriggers() returned empty lists as expected, suggesting the trigger behavior is cached or saved somewhere else when it should have been cleared when the configuration was removed.

          [JENKINS-72767] Removing ReverseBuildTrigger from Pipeline Job Does Not Take Effect

          Daniel Beck added a comment -

          Please provide steps to reproduce this situation. In particular, it would be interesting what specific actions constitute

          After this configuration was removed

          and

          Making further updates to the configuration for Pipeline Job B

          Daniel Beck added a comment - Please provide steps to reproduce this situation. In particular, it would be interesting what specific actions constitute After this configuration was removed and Making further updates to the configuration for Pipeline Job B

          Kurt Routley added a comment - - edited

          The job was configured using JobDSL. The initial JobDSL configuration for Downstream Pipeline Job B was like this:

          pipelineJob("DownstreamPipelineJobB") {
              triggers {
                  upstream {
                      upstreamProjects("UpstreamPipelineJobA")
                      threshold('SUCCESS')
                  }
              }
              properties {
                  pipelineTriggers {
                      triggers {
                          upstream {
                              upstreamProjects("UpstreamPipelineJobA")
                              threshold('SUCCESS')
                          }
                      }
                  }
              }
              ...
          } 

          I removed this configuration from the JobDSL file for Job B and re-ran the JobDSL seed, which removed the XML configuration (shown in the ticket description) for Job B. Kicking off a new run of upstream Job A after the JobDSL seed applied the configuration removal from Job B resulted in Job B still being triggered when Job A completed. 

          To see if there was potentially a stale configuration either in memory or on disk, I tried updating Job B's configuration through the UI (Job B's /configure page) by checking the "Quiet period" box under the "Build Triggers" section, confirmed there was no entry set for "Build after other projects are built", and saving the configuration. Note that there were no JobDSL seed runs after this manual configuration change (to rule out any JobDSL interference). Kicking off a new run of Job A, when Job A completed it still triggered Job B.

          Kurt Routley added a comment - - edited The job was configured using JobDSL. The initial JobDSL configuration for Downstream Pipeline Job B was like this: pipelineJob( "DownstreamPipelineJobB" ) {     triggers {         upstream {             upstreamProjects( "UpstreamPipelineJobA" )             threshold( 'SUCCESS' )         }     }     properties {         pipelineTriggers {             triggers {                 upstream {                     upstreamProjects( "UpstreamPipelineJobA" )                     threshold( 'SUCCESS' )                 }             }         }     }     ... } I removed this configuration from the JobDSL file for Job B and re-ran the JobDSL seed, which removed the XML configuration (shown in the ticket description) for Job B. Kicking off a new run of upstream Job A after the JobDSL seed applied the configuration removal from Job B resulted in Job B still being triggered when Job A completed.  To see if there was potentially a stale configuration either in memory or on disk, I tried updating Job B's configuration through the UI (Job B's /configure page) by checking the "Quiet period" box under the "Build Triggers" section, confirmed there was no entry set for "Build after other projects are built", and saving the configuration. Note that there were no JobDSL seed runs after this manual configuration change (to rule out any JobDSL interference). Kicking off a new run of Job A, when Job A completed it still triggered Job B.

          Kurt Routley added a comment -

          Checking on the Jenkins host file system, the build log entry for Job A appears like this:

          UpstreamPipelineJobA/builds/548/log:[2024-02-26T18:57:45.221Z] Triggering a new build of ha:////4FI8gmsn/Oy5ggG5C70fdtPfH0PvvcdUHoi9UadnVn1vAAAAqB+LCAAAAAAAAP9b85aBtbiIQTGjNKU4P08vOT+vOD8nVc83PyU1x6OyILUoJzMv2y+/JJUBAhiZGBgqihhk0NSjKDWzXb3RdlLBUSYGJk8GtpzUvPSSDB8G5tKinBIGIZ+sxLJE/ZzEvHT94JKizLx0a6BxUmjGOUNodHsLgAyxEgYZ/az8JP3gcPd8Dz1nT73g1KKy1CI9l9SCnPxKfQDoQ1q20QAAAA==DownstreamPipelineJobB #439
          

           

          Kurt Routley added a comment - Checking on the Jenkins host file system, the build log entry for Job A appears like this: UpstreamPipelineJobA/builds/548/log:[2024-02-26T18:57:45.221Z] Triggering a new build of ha: ////4FI8gmsn/Oy5ggG5C70fdtPfH0PvvcdUHoi9UadnVn1vAAAAqB+LCAAAAAAAAP9b85aBtbiIQTGjNKU4P08vOT+vOD8nVc83PyU1x6OyILUoJzMv2y+/JJUBAhiZGBgqihhk0NSjKDWzXb3RdlLBUSYGJk8GtpzUvPSSDB8G5tKinBIGIZ+sxLJE/ZzEvHT94JKizLx0a6BxUmjGOUNodHsLgAyxEgYZ/az8JP3gcPd8Dz1nT73g1KKy1CI9l9SCnPxKfQDoQ1q20QAAAA==DownstreamPipelineJobB #439  

          Daniel Beck added a comment -

          I removed this configuration from the JobDSL file for Job B and re-ran the JobDSL seed, which removed the XML configuration (shown in the ticket description) for Job B. 

          To clarify, you removed the entire snippeted excerpt, or just part of it?

          Why is triggers in there twice?

          Daniel Beck added a comment - I removed this configuration from the JobDSL file for Job B and re-ran the JobDSL seed, which removed the XML configuration (shown in the ticket description) for Job B.  To clarify, you removed the entire snippeted excerpt, or just part of it? Why is triggers in there twice?

          Kurt Routley added a comment - - edited

          I removed most of it, still needed the `pipelineJob` block for the job definition and `properties` for some additional settings, but removed the `triggers` and `pipelineTriggers` blocks.

          Both `triggers` and `pipelineTriggers` were present due to legacy config when we were updating to `properties -> pipelineTriggers` when `triggers` was marked as deprecated. We had found some cases where the polling configuration in `pipelineTriggers` wasn't being applied, so we had both blocks to ensure it was applied.

          Just now I safe restarted the Jenkins instance triggered Job A again, this time it is not triggering Job B, so restarting the instance seems to be a workaround for this. No Pipeline plugins were upgraded during the restart.

          Later in the week I'll try re-applying the settings to verify that it is reproducible and see if I can get a heap dump to see if there's any stale setting in memory, which would explain why the restart resolved the issue

          Kurt Routley added a comment - - edited I removed most of it, still needed the `pipelineJob` block for the job definition and `properties` for some additional settings, but removed the `triggers` and `pipelineTriggers` blocks. Both `triggers` and `pipelineTriggers` were present due to legacy config when we were updating to `properties -> pipelineTriggers` when `triggers` was marked as deprecated. We had found some cases where the polling configuration in `pipelineTriggers` wasn't being applied, so we had both blocks to ensure it was applied. Just now I safe restarted the Jenkins instance triggered Job A again, this time it is not triggering Job B, so restarting the instance seems to be a workaround for this. No Pipeline plugins were upgraded during the restart. Later in the week I'll try re-applying the settings to verify that it is reproducible and see if I can get a heap dump to see if there's any stale setting in memory, which would explain why the restart resolved the issue

          Daniel Beck added a comment -

          stale setting in memory, which would explain why the restart resolved the issue

          Agree, almost certainly some cache or something acting similarly is not being correctly updated.

          Ideally you'd be able to provide a minimal, reproducible example, e.g., using POST config.xml through the remote API or editing the file on disk, then /job/whatever/reload, rather than Job DSL.

          Daniel Beck added a comment - stale setting in memory, which would explain why the restart resolved the issue Agree, almost certainly some cache or something acting similarly is not being correctly updated. Ideally you'd be able to provide a minimal, reproducible example, e.g., using POST config.xml through the remote API or editing the file on disk, then /job/whatever/reload , rather than Job DSL.

            Unassigned Unassigned
            kroutley Kurt Routley
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: