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

SCM Trigger configuration being overwritten by SYSTEM user in Pipeline

    XMLWordPrintable

Details

    • Bug
    • Status: Resolved (View Workflow)
    • Major
    • Resolution: Not A Defect
    • pipeline
    • Jenkins 2.8
      BlueOcean 1.0.0-b17
      CentOS 6.7
      java version "1.7.0_101"
      OpenJDK Runtime Environment (rhel-2.6.6.4.el6_8-x86_64 u101-b00)
      OpenJDK 64-Bit Server VM (build 24.95-b01, mixed mode)

    Description

      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

      Attachments

        Issue Links

          Activity

            jglick Jesse Glick added a comment -

            As designed. I will emphasize this behavior in the step documentation though.

            jglick Jesse Glick added a comment - As designed. I will emphasize this behavior in the step documentation though.

            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.

            as_kumlali Ali Sadik Kumlali added a comment - 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
            Path:
            src/main/resources/org/jenkinsci/plugins/workflow/multibranch/JobPropertyStep/help.html
            http://jenkins-ci.org/commit/workflow-multibranch-plugin/5c7f723cd8b807a8c7ff10d349c55c531a2860ea
            Log:
            Emphasize JENKINS-41146.

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: src/main/resources/org/jenkinsci/plugins/workflow/multibranch/JobPropertyStep/help.html http://jenkins-ci.org/commit/workflow-multibranch-plugin/5c7f723cd8b807a8c7ff10d349c55c531a2860ea Log: Emphasize JENKINS-41146 .
            tknerr Torben Knerr added a comment -

            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:
            https://issues.jenkins-ci.org/browse/JENKINS-45053?focusedCommentId=304390&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-304390

            Not sure if this is a good idea really, but the best workaround I could find so far.

            jglick opinions?

            tknerr Torben Knerr added a comment - 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: https://issues.jenkins-ci.org/browse/JENKINS-45053?focusedCommentId=304390&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-304390 Not sure if this is a good idea really, but the best workaround I could find so far. jglick opinions?
            jglick Jesse Glick added a comment - See JENKINS-44848 . https://wiki.jenkins.io/display/JENKINS/Pipeline+Multibranch+Plugin

            People

              Unassigned Unassigned
              jonathandyer Jonathan Dyer
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: