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

Declarative is over-eager in deleting job properties not defined in the Jenkinsfile

XMLWordPrintable

      Before JENKINS-44149, Declarative only called the properties step if there was a JobProperty, Trigger, or ParameterDefinition specified in the Jenkinsfile. This was, in point of fact, not the right behavior - if you had a Trigger but no other JobProperty or ParameterDefinition and then you removed that Trigger from the Jenkinsfile, it wouldn't actually get removed from the job, since there were no JobProperty/Trigger/ParameterDefinition specified in the Jenkinsfile. So...with JENKINS-44149, we changed to instead call the properties step if there were no JobProperty/Trigger/ParameterDefinition as well. Hooray, correct behavior!

      Buuuuut.

      If you had never had any of those things in your Jenkinsfile but you were using a non-mulitbranch Pipeline and specifying triggers, properties, parameters, etc in the Jenkins UI for the standalone job, those now get wiped out, whether you like it or not. That is not ideal. We really should be only removing things that were defined in the Jenkinsfile previously.

          [JENKINS-44621] Declarative is over-eager in deleting job properties not defined in the Jenkinsfile

          Andrew Bayer created issue -
          Andrew Bayer made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]
          Andrew Bayer made changes -
          Status Original: In Progress [ 3 ] New: In Review [ 10005 ]

          Andrew Bayer added a comment -

          PR up at https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/160

          Andrew Bayer added a comment - PR up at https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/160
          Andrew Bayer made changes -
          Remote Link New: This issue links to "PR #160 (Web Link)" [ 16945 ]

          Michael Neale added a comment -

          nice one!

          Michael Neale added a comment - nice one!

          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/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/Options.groovy
          pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/Parameters.groovy
          pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/Triggers.groovy
          pipeline-model-definition/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/actions/JobPropertyTrackerAction.java
          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
          http://jenkins-ci.org/commit/pipeline-model-definition-plugin/d07d3501b898cf3087716e12004021d8c703efea
          Log:
          [FIXED JENKINS-44621] Only remove job properties from Jenkinsfiles

          Rather than actually using the properties(...) step directly, we
          instead will now do this behind the scenes by interacting with the job
          directly. We'll also record what job properties, triggers, and
          parameters were defined in the Jenkinsfile for a given run, so that we
          can refer back in the next build to see what existing job properties,
          triggers, or parameters were defined through the Jenkinsfile vs
          defined outside of the Jenkinsfile. This way, we can preserve the
          defined-outside-Jenkinsfile properties et al.

          Note that this won't quite work right if the first run of a job
          after upgrading removes triggers/properties/etc, because there is no
          record for builds beforehand, so all properties etc on the job at the
          time of upgrade will be treated as if they were defined
          externally. However, after that first build, you can remove properties
          etc from the Jenkinsfile with the expected behavior.

          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/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/Options.groovy pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/Parameters.groovy pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/Triggers.groovy pipeline-model-definition/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/actions/JobPropertyTrackerAction.java 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 http://jenkins-ci.org/commit/pipeline-model-definition-plugin/d07d3501b898cf3087716e12004021d8c703efea Log: [FIXED JENKINS-44621] Only remove job properties from Jenkinsfiles Rather than actually using the properties(...) step directly, we instead will now do this behind the scenes by interacting with the job directly. We'll also record what job properties, triggers, and parameters were defined in the Jenkinsfile for a given run, so that we can refer back in the next build to see what existing job properties, triggers, or parameters were defined through the Jenkinsfile vs defined outside of the Jenkinsfile. This way, we can preserve the defined-outside-Jenkinsfile properties et al. Note that this won't quite work right if the first run of a job after upgrading removes triggers/properties/etc, because there is no record for builds beforehand, so all properties etc on the job at the time of upgrade will be treated as if they were defined externally. However, after that first build, you can remove properties etc from the Jenkinsfile with the expected behavior.
          Andrew Bayer made changes -
          Resolution New: Fixed [ 1 ]
          Status Original: In Review [ 10005 ] New: Resolved [ 5 ]

          Reinhold Füreder added a comment -

          If I replay a build with different job properties (e.g. buildDiscarder in options of declarative pipeline): is that supposed to modify the job as well? (presumably yes, and it is actually the case)

          Can you log if such job property are changed?

          Reinhold Füreder added a comment - If I replay a build with different job properties (e.g. buildDiscarder in options of declarative pipeline): is that supposed to modify the job as well? (presumably yes, and it is actually the case) Can you log if such job property are changed?
          Andrew Bayer made changes -
          Link New: This issue is duplicated by JENKINS-42785 [ JENKINS-42785 ]

            abayer Andrew Bayer
            abayer Andrew Bayer
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: