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
            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.
            Hide
            bitwiseman Liam Newman added a comment -

            Bulk closing resolved issues.

            Show
            bitwiseman Liam Newman added a comment - Bulk closing resolved issues.

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: