-
Bug
-
Resolution: Fixed
-
Minor
-
None
-
pipeline-model-definition-plugin 1.1.3
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.
- is duplicated by
-
-
- Closed
-
- links to
[JENKINS-44149] Removing triggers block does not remove triggers from config.xml
So on the initial issue - the second run of the upstream job does trigger the downstream job but shouldn't?
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).
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.
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. 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.
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.
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.
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.