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

SCM Trigger configuration being overwritten by SYSTEM user in Pipeline

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Not A Defect
    • Component/s: pipeline
    • Environment:
      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)
    • Similar Issues:

      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

            Hide
            jglick Jesse Glick added a comment -

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

            Show
            jglick Jesse Glick added a comment - As designed. I will emphasize this behavior in the step documentation though.
            Hide
            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.

            Show
            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.
            Hide
            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.

            Show
            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 .
            Hide
            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.

            Jesse Glick opinions?

            Show
            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. Jesse Glick opinions?
            Show
            jglick Jesse Glick added a comment - See JENKINS-44848 . https://wiki.jenkins.io/display/JENKINS/Pipeline+Multibranch+Plugin

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: