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

Job DSL does not track manual changes correctly

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Fixed but Unreleased (View Workflow)
    • Priority: Minor
    • Resolution: Not A Defect
    • Component/s: job-dsl-plugin
    • Labels:
      None
    • Similar Issues:

      Description

      The following Job DSL creates a job called test that will always show the message "This item has been changed manually since it was generated by the seed job." after test has been triggered:

      pipelineJob('test') {
          definition {
              cps {
                  script('''
                      pipeline {
                          agent any
                          stages {
                              stage('build') {
                                  steps {
                                      echo 'building'
                                  }
                              }
                          }
                      }
                  ''')
              }
          }
      }
      

        Attachments

          Activity

          Hide
          daspilker Daniel Spilker added a comment -

          The problem is that some plugin (I assume it's Declarative Pipeline) modifies the configuration during or after a build. Job DSL can't differentiate between user changes and automatic changes, so it's will show the warning. IMHO it's debatable if a plugin should modify the job configuration instead of storing the information in build. There are other plugins that also modify the configuration. And that causes issues for other plugins as well, e.g. for the Job Config History plugin.

          Configuration generated by Job DSL:

          <?xml version="1.0" encoding="UTF-8"?><flow-definition>
              <actions/>
              <description/>
              <keepDependencies>false</keepDependencies>
              <properties/>
              <triggers/>
              <definition class="org.jenkinsci.plugins.workflow.cps.CpsFlowDefinition">
                  <script>
                          pipeline {
                              agent any
                              stages {
                                  stage('build') {
                                      steps {
                                          echo 'building'
                                      }
                                  }
                              }
                          }
                      </script>
                  <sandbox>false</sandbox>
              </definition>
          </flow-definition>
          

          Configuration after first build:

          <?xml version='1.0' encoding='UTF-8'?>
          <flow-definition plugin="workflow-job@2.21">
            <actions>
              <org.jenkinsci.plugins.pipeline.modeldefinition.actions.DeclarativeJobAction plugin="pipeline-model-definition@1.3.1"/>
            </actions>
            <description></description>
            <keepDependencies>false</keepDependencies>
            <properties/>
            <definition class="org.jenkinsci.plugins.workflow.cps.CpsFlowDefinition" plugin="workflow-cps@2.53">
              <script>
                          pipeline {
                              agent any
                              stages {
                                  stage(&apos;build&apos;) {
                                      steps {
                                          echo &apos;building&apos;
                                      }
                                  }
                              }
                          }
                      </script>
              <sandbox>false</sandbox>
            </definition>
            <triggers/>
            <disabled>false</disabled>
          </flow-definition>
          
          Show
          daspilker Daniel Spilker added a comment - The problem is that some plugin (I assume it's Declarative Pipeline) modifies the configuration during or after a build. Job DSL can't differentiate between user changes and automatic changes, so it's will show the warning. IMHO it's debatable if a plugin should modify the job configuration instead of storing the information in build. There are other plugins that also modify the configuration. And that causes issues for other plugins as well, e.g. for the Job Config History plugin. Configuration generated by Job DSL: <?xml version= "1.0" encoding= "UTF-8" ?><flow-definition> <actions/> <description/> <keepDependencies> false </keepDependencies> <properties/> <triggers/> <definition class= "org.jenkinsci.plugins.workflow.cps.CpsFlowDefinition" > <script> pipeline { agent any stages { stage( 'build' ) { steps { echo 'building' } } } } </script> <sandbox> false </sandbox> </definition> </flow-definition> Configuration after first build: <?xml version= '1.0' encoding= 'UTF-8' ?> <flow-definition plugin= "workflow-job@2.21" > <actions> <org.jenkinsci.plugins.pipeline.modeldefinition.actions.DeclarativeJobAction plugin= "pipeline-model-definition@1.3.1" /> </actions> <description></description> <keepDependencies> false </keepDependencies> <properties/> <definition class= "org.jenkinsci.plugins.workflow.cps.CpsFlowDefinition" plugin= "workflow-cps@2.53" > <script> pipeline { agent any stages { stage(&apos;build&apos;) { steps { echo &apos;building&apos; } } } } </script> <sandbox> false </sandbox> </definition> <triggers/> <disabled> false </disabled> </flow-definition>
          Hide
          aszostak Artur Szostak added a comment -

          I do not agree with the assessment that this is not a defect. It is fundamentally a design flaw. I am not saying it is necessarily the job-dsl-plugin's fault. But clearly the set of assumptions and working model that it is using is not compatible with other plugins. If this software was standalone one could say, tough luck, that is just how the thing works. But it is not standalone. It is a plugin that forms part of a larger system. Therefore I consider it a design flaw.
          Very likely it is not currently solvable by the job-dsl-plugin, because as you mention, Jenkins does not provide a mechanism to distinguish manual from automatic modifications. But then this should be raised with the core system, rather than dismissing it as not a flaw.

          Show
          aszostak Artur Szostak added a comment - I do not agree with the assessment that this is not a defect. It is fundamentally a design flaw. I am not saying it is necessarily the job-dsl-plugin's fault. But clearly the set of assumptions and working model that it is using is not compatible with other plugins. If this software was standalone one could say, tough luck, that is just how the thing works. But it is not standalone. It is a plugin that forms part of a larger system. Therefore I consider it a design flaw. Very likely it is not currently solvable by the job-dsl-plugin, because as you mention, Jenkins does not provide a mechanism to distinguish manual from automatic modifications. But then this should be raised with the core system, rather than dismissing it as not a flaw.
          Hide
          spinus1 Alessio Moscatello added a comment -

          Hello,

          I'm experiencing a similar issue, but in a more complicated workflow: I have a DSL job that creates other jobs and these jobs are using separate repository to get the pipeline code to be executed: the DSL plugin always report that the job has been manually modified.

          Maybe the DSL plugin could be modified to compare current Job configuration to the one generated by the first run of the pipeline and not to the configuration generated by DSL plugin itself?

           

          BR,

          Alessio

          Show
          spinus1 Alessio Moscatello added a comment - Hello, I'm experiencing a similar issue, but in a more complicated workflow: I have a DSL job that creates other jobs and these jobs are using separate repository to get the pipeline code to be executed: the DSL plugin always report that the job has been manually modified. Maybe the DSL plugin could be modified to compare current Job configuration to the one generated by the first run of the pipeline and not to the configuration generated by DSL plugin itself?   BR, Alessio
          Hide
          jansohn Robin Jansohn added a comment -

          Artur Szostak have you raised an issue with the core system for this problem? I agree with you that the current behavior is fundamentally flawed...

          Show
          jansohn Robin Jansohn added a comment - Artur Szostak have you raised an issue with the core system for this problem? I agree with you that the current behavior is fundamentally flawed...
          Hide
          aszostak Artur Szostak added a comment -

          No, I have not raised this issue any further, since I do not know the Jenkins development model well enough to know where to send the report and how to structure it to make any sense. The only obvious report I could think of making was this ticket with a reproducible example for job-dsl-plugin. I rely on actual Jenkins developers with far more knowledge about the internals to triage the tickets and redirect them to the appropriate place as necessary.

          Show
          aszostak Artur Szostak added a comment - No, I have not raised this issue any further, since I do not know the Jenkins development model well enough to know where to send the report and how to structure it to make any sense. The only obvious report I could think of making was this ticket with a reproducible example for job-dsl-plugin . I rely on actual Jenkins developers with far more knowledge about the internals to triage the tickets and redirect them to the appropriate place as necessary.
          Hide
          danep Dane Powell added a comment -

          Has anyone made progress on this issue? Sounds like not. I've only seen sporadic reports about individual plugins being fixed.

          I opened an issue for the Pipelines Job plugin: JENKINS-63173

          I'm surprised this issue hasn't gotten more traction, doesn't this behavior make the job config history basically useless, and therefore difficult to audit? Doesn't that worry any other enterprise administrators?

          Show
          danep Dane Powell added a comment - Has anyone made progress on this issue? Sounds like not. I've only seen sporadic reports about individual plugins being fixed. I opened an issue for the Pipelines Job plugin:  JENKINS-63173 I'm surprised this issue hasn't gotten more traction, doesn't this behavior make the job config history basically useless, and therefore difficult to audit? Doesn't that worry any other enterprise administrators?

            People

            Assignee:
            jamietanna Jamie Tanna
            Reporter:
            aszostak Artur Szostak
            Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: