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>

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.

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

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

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.

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?