Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
None
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
- is duplicated by
-
JENKINS-42785 Parameterized Pipeline Projects have their Build Triggers unset after each build
-
- Closed
-
- links to
Activity
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.
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?
PR up at https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/160