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

Removing triggers block does not remove triggers from config.xml

    Details

    • Similar Issues:

      Description

      Create a pipeline with the following configuration and run the job.

      pipeline {
          agent {
              label 'my_label'
          }
      
          triggers {
              upstream upstreamProjects: 'upstream', threshold: hudson.model.Result.SUCCESS
          }
      
          options{
              timestamps()
          }
      
          stages {
              stage('build') {
                  steps {
                      echo 'building'
                  }
              }
          }
      

      Create another job (upstream) in the same folder and run it (should see original pipeline is triggered).

      Remove triggers from original pipeline, rerun it (to ensure a new config.xml could be generated)

      Rerun upstream job

      The second run should trigger the pipeline job. What I've done in the past to workaround this is to put in a bogus upstream job in triggers to force a rewrite of config.xml.

        Attachments

          Issue Links

            Activity

            Hide
            rpocase Robby Pocase added a comment -

            I've hit a similar issue with default parameter values. Not sure if its the same workflow or not, but may warrant a new issue.

            pipeline {
              agent {
                label 'label'
              }
              parameters {
                booleanParam(name: 'DO_THE_THING', defaultValue: false, description: 'Do the thing that needs enabling')
              }
              ... 
            }
            
            

             

            Changing the default in source control doesn't appear to propagate to the job until manually kicking off the build. I haven't retested with other parameter value types.

            Show
            rpocase Robby Pocase added a comment - I've hit a similar issue with default parameter values. Not sure if its the same workflow or not, but may warrant a new issue. pipeline {   agent {     label 'label'   }   parameters {     booleanParam(name: 'DO_THE_THING' , defaultValue: false , description: 'Do the thing that needs enabling' )   } ... }   Changing the default in source control doesn't appear to propagate to the job until manually kicking off the build. I haven't retested with other parameter value types.
            Hide
            abayer Andrew Bayer added a comment -

            So on the initial issue - the second run of the upstream job does trigger the downstream job but shouldn't?

            Show
            abayer Andrew Bayer added a comment - So on the initial issue - the second run of the upstream job does trigger the downstream job but shouldn't?
            Hide
            abayer Andrew Bayer added a comment -

            And on the second issue - you're saying the change to the parameter doesn't take effect on a triggered-by-SCM-change build, only a manual one? Because it's expected that it won't change until any run of the job (since it's gotta run the properties step behind the scenes to actually change anything in the job config).

            Show
            abayer Andrew Bayer added a comment - And on the second issue - you're saying the change to the parameter doesn't take effect on a triggered-by-SCM-change build, only a manual one? Because it's expected that it won't change until any run of the job (since it's gotta run the properties step behind the scenes to actually change anything in the job config).
            Hide
            rpocase Robby Pocase added a comment -

            For the first issue, yes.

            The second issue I may need to go back and re-test. What we observed was:

            • Changing SCM triggered the job using the old default value
            • Manual trigger correctly used the new default value
            • Next SCM trigger correctly used the new default value

            It could be that the initial change by SCM was stuck on the old value but updated properties under the hood for the next run. I'll have to test two SCM changes back to back - I have no data on that path currently.

            Show
            rpocase Robby Pocase added a comment - For the first issue, yes. The second issue I may need to go back and re-test. What we observed was: Changing SCM triggered the job using the old default value Manual trigger correctly used the new default value Next SCM trigger correctly used the new default value It could be that the initial change by SCM was stuck on the old value but updated properties under the hood for the next run. I'll have to test two SCM changes back to back - I have no data on that path currently.
            Hide
            abayer Andrew Bayer added a comment -

            So since Build #X is going to be using the parameters set in Build #X-1, here's how I would expect things to go, regardless of how the builds get kicked off:

            • Build #1: No parameters defined when build starts since job has never run before, parameters get defined during the build (when the properties step gets called behind the scenes. Parameters with default values will work with params.SOME_PARAM, because that logic says "Ok, if SOME_PARAM is not in the parameters that were passed to the build when we started, but it is defined in the job config now, make params.SOME_PARAM return the default value specified in the job config."
            • Build #2: Parameters are set as expected both at launch time and during the build.
            • Build #3: First build after changing the Jenkinsfile to a new defaultValue. The parameters set at launch time are using the job config as of the end of the previous build - i.e., SOME_PARAM has its old defaultValue, so params.SOME_PARAM will return the old value. But if you added a new parameter, SOME_OTHER_PARAM, and then reference it as params.SOME_OTHER_PARAM, it'll get the defaultValue specified in this latest version of the Jenkinsfile. Since the properties step is being called behind the scenes during the build, the job config will be updated so that SOME_PARAM has the new defaultValue in the job config for every future build.
            • Build #4: Parameters are set as expected both at launch time and during the build - i.e., SOME_PARAM has the new defaultValue.

            This is admittedly kind of ass.

            Show
            abayer Andrew Bayer added a comment - So since Build #X is going to be using the parameters set in Build #X-1, here's how I would expect things to go, regardless of how the builds get kicked off: Build #1: No parameters defined when build starts since job has never run before, parameters get defined during the build (when the properties step gets called behind the scenes. Parameters with default values will work with params.SOME_PARAM , because that logic says "Ok, if SOME_PARAM is not in the parameters that were passed to the build when we started, but it is defined in the job config now, make params.SOME_PARAM return the default value specified in the job config." Build #2: Parameters are set as expected both at launch time and during the build. Build #3: First build after changing the Jenkinsfile to a new defaultValue . The parameters set at launch time are using the job config as of the end of the previous build - i.e., SOME_PARAM has its old defaultValue , so params.SOME_PARAM will return the old value. But if you added a new parameter, SOME_OTHER_PARAM , and then reference it as params.SOME_OTHER_PARAM , it'll get the defaultValue specified in this latest version of the Jenkinsfile. Since the properties step is being called behind the scenes during the build, the job config will be updated so that SOME_PARAM has the new defaultValue in the job config for every future build. Build #4: Parameters are set as expected both at launch time and during the build - i.e., SOME_PARAM has the new defaultValue . This is admittedly kind of ass.
            Hide
            abayer Andrew Bayer added a comment -

            PR up for the triggers thing - there was a legit problem with job properties (including triggers and parameters) not getting removed when options, triggers and parameters in the Jenkinsfile all were changed to not be present any more. This fixes that behavior.

            Show
            abayer Andrew Bayer added a comment - PR up for the triggers thing - there was a legit problem with job properties (including triggers and parameters) not getting removed when options , triggers and parameters in the Jenkinsfile all were changed to not be present any more. This fixes that behavior.
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Andrew Bayer
            Path:
            pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/Utils.groovy
            pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/ModelInterpreter.groovy
            pipeline-model-definition/src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/OptionsTest.java
            pipeline-model-definition/src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/ParametersTest.java
            pipeline-model-definition/src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/TriggersTest.java
            pipeline-model-definition/src/test/resources/propsTriggersParamsRemoved.groovy
            http://jenkins-ci.org/commit/pipeline-model-definition-plugin/71a6001202218266ea16c18f37a86b4af17d7459
            Log:
            [FIXED JENKINS-44149] Probably clean up old props/triggers/params

            Previously we weren't calling the properties step if there were no
            properties (i.e., no job properties from options, no triggers, no
            parameters), but that left lurking properties when you removed all
            properties, triggers and parameters from the Jenkinsfile. So now let's
            check the job config to see if there were already defined properties
            before deciding not to call the properties step. Also make sure that
            PipelineTriggersJobProperty and ParametersDefinitionProperty are not
            empty, rather than just present.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Andrew Bayer Path: pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/Utils.groovy pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/ModelInterpreter.groovy pipeline-model-definition/src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/OptionsTest.java pipeline-model-definition/src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/ParametersTest.java pipeline-model-definition/src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/TriggersTest.java pipeline-model-definition/src/test/resources/propsTriggersParamsRemoved.groovy http://jenkins-ci.org/commit/pipeline-model-definition-plugin/71a6001202218266ea16c18f37a86b4af17d7459 Log: [FIXED JENKINS-44149] Probably clean up old props/triggers/params Previously we weren't calling the properties step if there were no properties (i.e., no job properties from options, no triggers, no parameters), but that left lurking properties when you removed all properties, triggers and parameters from the Jenkinsfile. So now let's check the job config to see if there were already defined properties before deciding not to call the properties step. Also make sure that PipelineTriggersJobProperty and ParametersDefinitionProperty are not empty, rather than just present.
            Hide
            abayer Andrew Bayer added a comment -

            Fixed in upcoming 1.1.5.

            Show
            abayer Andrew Bayer added a comment - Fixed in upcoming 1.1.5.

              People

              • Assignee:
                abayer Andrew Bayer
                Reporter:
                rpocase Robby Pocase
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: