Status: Resolved (View Workflow)
Resolution: Not A Defect
java version "1.7.0_101"
OpenJDK Runtime Environment (rhel-18.104.22.168.el6_8-x86_64 u101-b00)
OpenJDK 64-Bit Server VM (build 24.95-b01, mixed mode)
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
JENKINS-41072 Poll the GitHub Events API as an alternative to webhook
JENKINS-41073 MultiBranch projects should veto SCM Polling
JENKINS-45053 EnvInject Properties are lost when 'properties' is used in a pipeline step
- links to
workflow-multibranch's documentation for properties step is not clear in that manner. It only says properties step "updates" the properties. It is not clear that it will override all properties configured in this job, either from the UI or from an earlier properties step.
properties: Set job properties
Updates the properties of the job which runs this step. Mainly useful from multibranch Pipelines, so that Jenkinsfile itself can encode what would otherwise be static job configuration.
Code changed in jenkins
User: Jesse Glick
Imho it would be really useful if the `properties` step would provide an additive behaviour as an optional alternative to the current destructive behaviour.
For now I'm working around this by using the Jenkins API directly instead of the Pipeline DSL's `properties` step:
Not sure if this is a good idea really, but the best workaround I could find so far.
As designed. I will emphasize this behavior in the step documentation though.