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

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

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      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.

        Attachments

          Issue Links

            Activity

            Hide
            reinholdfuereder 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?

            Show
            reinholdfuereder 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?
            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/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.

            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/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.
            Hide
            michaelneale Michael Neale added a comment -

            nice one!

            Show
            michaelneale Michael Neale added a comment - nice one!
            Show
            abayer Andrew Bayer added a comment - PR up at https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/160

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: