Major I setup a Pipeline job using a Pipeline script written in the job (not in SCM) and enabled SCM polling as a Build Trigger.
The polling mechanism works and triggers a build after detecting changes, however whenever it polls there is a high chance that the config.xml will be modified, removing the SCM Trigger entirely.
I used the Job Configuration History plugin and it shows the changes happening from SYSTEM user.
Looking through jenkins.log doesn't provide much information either, as this is the only entry around the same time as the SYSTEM user updates the config.xml
Jan 17, 2017 2:17:24 PM hudson.triggers.SCMTrigger$Runner run
INFO: SCM changes detected in unified-trunk. Triggering #84
- is related to
-
JENKINS-41074 UX Issue with Polling in Multibranch Pipeline
-
- Open
-
-
JENKINS-41072 Poll the GitHub Events API as an alternative to webhook
-
- Open
-
-
-
- Open
-
-
-
- Resolved
-
- links to
[JENKINS-41146] SCM Trigger configuration being overwritten by SYSTEM user in Pipeline
Jonathan Dyer
created issue -
Jonathan Dyer
made changes -
| Description |
Original:
I setup a Pipeline job using a Pipeline script written in the job (not in SCM) and enabled SCM polling as a Build Trigger. The polling mechanism works and triggers a build after detecting changes, however whenever it polls there is a high chance that the config.xml will be modified, removing the SCM Trigger entirely. !image-2017-01-17-14-43-37-557.png|thumbnail! I used the Job Configuration History plugin and it shows the changes happening from SYSTEM user. !image-2017-01-17-14-41-29-596.png|thumbnail! |
New:
I setup a Pipeline job using a Pipeline script written in the job (not in SCM) and enabled SCM polling as a Build Trigger. The polling mechanism works and triggers a build after detecting changes, however whenever it polls there is a high chance that the config.xml will be modified, removing the SCM Trigger entirely. !image-2017-01-17-14-43-37-557.png|thumbnail! I used the Job Configuration History plugin and it shows the changes happening from SYSTEM user. !image-2017-01-17-14-41-29-596.png|thumbnail! Looking through jenkins.log doesn't provide much information either, as this is the only entry around the same time as the SYSTEM user updates the config.xml {quote} Jan 17, 2017 2:17:24 PM hudson.triggers.SCMTrigger$Runner run INFO: SCM changes detected in unified-trunk. Triggering #84 {quote} |
jonathandyer would you be able to post the Pipeline here that demonstrated the original problem? We might be able to make the error handling here a lot better.
| Component/s | Original: blueocean-plugin [ 21481 ] |
Jonathan Dyer
added a comment - // Setup Job properties properties([buildDiscarder(logRotator(artifactDaysToKeepStr: '', artifactNumToKeepStr: '', daysToKeepStr: '30', numToKeepStr: '')), disableConcurrentBuilds(), pipelineTriggers([])])
The offending bit is "pipelineTriggers([])".
It's now my understanding that any properties defined within the pipeline script will supersede and overwrite on disk the properties manually set on the Job itself.
I have tested this theory and created a job with a single build parameter, then used the exact same properties I noted above which has no mention of build parameters. The initial run allowed me to select a build parameter, but after that the config changed and it was no longer an option.
So it appears that pipeline properties will override all configurations it is able to, regardless if specified within the pipeline script or not.
Jonathan Dyer
added a comment - jamesdumay ,
// Setup Job properties
properties([buildDiscarder(logRotator(artifactDaysToKeepStr: '', artifactNumToKeepStr: ' ', daysToKeepStr: ' 30 ', numToKeepStr: ' ')), disableConcurrentBuilds(), pipelineTriggers([])])
The offending bit is "pipelineTriggers([])".
It's now my understanding that any properties defined within the pipeline script will supersede and overwrite on disk the properties manually set on the Job itself.
I have tested this theory and created a job with a single build parameter, then used the exact same properties I noted above which has no mention of build parameters. The initial run allowed me to select a build parameter, but after that the config changed and it was no longer an option.
So it appears that pipeline properties will override all configurations it is able to, regardless if specified within the pipeline script or not. Jonathan Dyer
added a comment - An even more simple test of a pipeline job with just
properties([])
will cause all properties to be overwritten/removed with defaults.
Jonathan Dyer
added a comment - An even more simple test of a pipeline job with just
properties([])
will cause all properties to be overwritten/removed with defaults. | Link | New: This issue is related to JENKINS-41072 [ JENKINS-41072 ] |
| Link | New: This issue is related to JENKINS-41073 [ JENKINS-41073 ] |
| Link | New: This issue is related to JENKINS-41074 [ JENKINS-41074 ] |
I've discovered the issue, in my pipeline script I was defining job properties and it had an empty pipelineTriggers section.
It wasn't clear to me that this script would actually modify the config.xml on the master, and that not using a build trigger initially in the snippet generator it would default to being empty thus removing any build triggers within the config.xml.