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

Conflicting behavior - Job updated using DSL removes trigger definitions created by Jenkinsfile in a pipeline job

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • job-dsl-plugin
    • None

      Environment

      Jenkins 2.280

      Job DSL Plugin 1.77

      Description

      Given the current (and arguably awkward) behavior of Pipeline jobs (JENKINS-50365), several values, such as triggers and parameters, are only reloaded after the job runs.

      This behavior conflicts with the fact that Job DSL scripts completely overwrite trigger definitions created by the Pipeline script.

      While trying to keep a fully automated job maintenance routine, we load Job DSLs using the JCasC plugin. Our Job DSLs are minimal and define only a directive to load the Jenkinsfile from a remote SCM.

      In practice, we are unable to keep trigger and parameter definitions in the Jenkinsfile. Everytime a clean Job DSL is reloaded, all triggers and parameters created by the Jenkinsfile are lost.

      Workaround

      The only workaround we found is to keep triggers and parameters defined outside the Jenkinsfile, in the Job DSL.

      Steps to reproduce

      1. Install Job DSL Plugin
      2. Install JCasC plugin (or use a seed job to load DSLs)
      3. Create a Job using DSL that loads a remote Jenkinsfile from SCM
      4. Define job triggers in the Jenkinsfile
      5. Define job paramteres in the Jenkinsfile
      6. Run the job once
      7. Check job configuration (triggers and parameters will be there)
      8. Reload the DSL
      9. Check job configuration (triggers and parameters will be lost).

        1. image-2021-05-04-13-00-41-893.png
          image-2021-05-04-13-00-41-893.png
          60 kB

          [JENKINS-64918] Conflicting behavior - Job updated using DSL removes trigger definitions created by Jenkinsfile in a pipeline job

          Julio Morimoto created issue -
          Julio Morimoto made changes -
          Description Original: h1. Environment

          Jenkins 2.280

          Job DSL Plugin 1.77
          h1. Description

          Given the current (and arguably awkward) behavior of Pipeline jobs (JENKINS-50365), several values, such as triggers and parameters are only reloaded after the job runs.

          This behavior conflicts with the fact that Job DSL scripts complete overwrite trigger definitions created by the Pipeline script.

          While trying to keep a fully automated job maintenance routine, we load Job DSLs using the JCasC plugin. Our Job DSLs are minimal and define only a directive to load Jenkins from a remote SCM.

          In practice, we are unable to keep trigger definitions in the Jenkinsfile. Everytime a clean Job DSL is reloaded, all triggers created by the Jenkinsfile are lost.

          This only affect triggers. Job parameters are still left intact, once defined by the Jenkinsfile.
          h1. Workaround

          The only workaround we found is to keep triggers defined outside the Jenkinsfile, in the Job DSL.
          h1. Steps to reproduce
           # Install Job DSL Plugin
           # Install JCasC plugin (or use a seed job to load DSLs)
           # Create a Job using DSL that loads a remote Jenkinsfile from SCM
           # Define job triggers in the Jenkinsfile
           # Define job paramteres in the Jenkinsfile
           # Run the job once
           # Check job configuration (triggers and parameters will be there)
           # Reload the DSL
           # Check job configuration (triggers will be lost, but parameters will be there).           		New: h1. Environment

          Jenkins 2.280

          Job DSL Plugin 1.77
          h1. Description

          Given the current (and arguably awkward) behavior of Pipeline jobs (JENKINS-50365), several values, such as triggers and parameters, are only reloaded after the job runs.

          This behavior conflicts with the fact that Job DSL scripts complete overwrite trigger definitions created by the Pipeline script.

          While trying to keep a fully automated job maintenance routine, we load Job DSLs using the JCasC plugin. Our Job DSLs are minimal and define only a directive to load Jenkins from a remote SCM.

          In practice, we are unable to keep trigger definitions in the Jenkinsfile. Everytime a clean Job DSL is reloaded, all triggers created by the Jenkinsfile are lost.

          This only affect triggers. Job parameters are still left intact, once defined by the Jenkinsfile.
          h1. Workaround

          The only workaround we found is to keep triggers defined outside the Jenkinsfile, in the Job DSL.
          h1. Steps to reproduce
           # Install Job DSL Plugin
           # Install JCasC plugin (or use a seed job to load DSLs)
           # Create a Job using DSL that loads a remote Jenkinsfile from SCM
           # Define job triggers in the Jenkinsfile
           # Define job paramteres in the Jenkinsfile
           # Run the job once
           # Check job configuration (triggers and parameters will be there)
           # Reload the DSL
           # Check job configuration (triggers will be lost, but parameters will be there).
          Julio Morimoto made changes -
          Description Original: h1. Environment

          Jenkins 2.280

          Job DSL Plugin 1.77
          h1. Description

          Given the current (and arguably awkward) behavior of Pipeline jobs (JENKINS-50365), several values, such as triggers and parameters, are only reloaded after the job runs.

          This behavior conflicts with the fact that Job DSL scripts complete overwrite trigger definitions created by the Pipeline script.

          While trying to keep a fully automated job maintenance routine, we load Job DSLs using the JCasC plugin. Our Job DSLs are minimal and define only a directive to load Jenkins from a remote SCM.

          In practice, we are unable to keep trigger definitions in the Jenkinsfile. Everytime a clean Job DSL is reloaded, all triggers created by the Jenkinsfile are lost.

          This only affect triggers. Job parameters are still left intact, once defined by the Jenkinsfile.
          h1. Workaround

          The only workaround we found is to keep triggers defined outside the Jenkinsfile, in the Job DSL.
          h1. Steps to reproduce
           # Install Job DSL Plugin
           # Install JCasC plugin (or use a seed job to load DSLs)
           # Create a Job using DSL that loads a remote Jenkinsfile from SCM
           # Define job triggers in the Jenkinsfile
           # Define job paramteres in the Jenkinsfile
           # Run the job once
           # Check job configuration (triggers and parameters will be there)
           # Reload the DSL
           # Check job configuration (triggers will be lost, but parameters will be there).           		New: h1. Environment

          Jenkins 2.280

          Job DSL Plugin 1.77
          h1. Description

          Given the current (and arguably awkward) behavior of Pipeline jobs (JENKINS-50365), several values, such as triggers and parameters, are only reloaded after the job runs.

          This behavior conflicts with the fact that Job DSL scripts complete overwrite trigger definitions created by the Pipeline script.

          While trying to keep a fully automated job maintenance routine, we load Job DSLs using the JCasC plugin. Our Job DSLs are minimal and define only a directive to load Jenkins from a remote SCM.

          In practice, we are unable to keep trigger definitions in the Jenkinsfile. Everytime a clean Job DSL is reloaded, all triggers and parameters created by the Jenkinsfile are lost.
          h1. Workaround

          The only workaround we found is to keep triggers defined outside the Jenkinsfile, in the Job DSL.
          h1. Steps to reproduce
           # Install Job DSL Plugin
           # Install JCasC plugin (or use a seed job to load DSLs)
           # Create a Job using DSL that loads a remote Jenkinsfile from SCM
           # Define job triggers in the Jenkinsfile
           # Define job paramteres in the Jenkinsfile
           # Run the job once
           # Check job configuration (triggers and parameters will be there)
           # Reload the DSL
           # Check job configuration (triggers and parameters will be lost).
          Julio Morimoto made changes -
          Description Original: h1. Environment

          Jenkins 2.280

          Job DSL Plugin 1.77
          h1. Description

          Given the current (and arguably awkward) behavior of Pipeline jobs (JENKINS-50365), several values, such as triggers and parameters, are only reloaded after the job runs.

          This behavior conflicts with the fact that Job DSL scripts complete overwrite trigger definitions created by the Pipeline script.

          While trying to keep a fully automated job maintenance routine, we load Job DSLs using the JCasC plugin. Our Job DSLs are minimal and define only a directive to load Jenkins from a remote SCM.

          In practice, we are unable to keep trigger definitions in the Jenkinsfile. Everytime a clean Job DSL is reloaded, all triggers and parameters created by the Jenkinsfile are lost.
          h1. Workaround

          The only workaround we found is to keep triggers defined outside the Jenkinsfile, in the Job DSL.
          h1. Steps to reproduce
           # Install Job DSL Plugin
           # Install JCasC plugin (or use a seed job to load DSLs)
           # Create a Job using DSL that loads a remote Jenkinsfile from SCM
           # Define job triggers in the Jenkinsfile
           # Define job paramteres in the Jenkinsfile
           # Run the job once
           # Check job configuration (triggers and parameters will be there)
           # Reload the DSL
           # Check job configuration (triggers and parameters will be lost).           		New: h1. Environment

          Jenkins 2.280

          Job DSL Plugin 1.77
          h1. Description

          Given the current (and arguably awkward) behavior of Pipeline jobs (JENKINS-50365), several values, such as triggers and parameters, are only reloaded after the job runs.

          This behavior conflicts with the fact that Job DSL scripts complete overwrite trigger definitions created by the Pipeline script.

          While trying to keep a fully automated job maintenance routine, we load Job DSLs using the JCasC plugin. Our Job DSLs are minimal and define only a directive to load the Jenkinsfile from a remote SCM.

          In practice, we are unable to keep trigger definitions in the Jenkinsfile. Everytime a clean Job DSL is reloaded, all triggers and parameters created by the Jenkinsfile are lost.
          h1. Workaround

          The only workaround we found is to keep triggers defined outside the Jenkinsfile, in the Job DSL.
          h1. Steps to reproduce
           # Install Job DSL Plugin
           # Install JCasC plugin (or use a seed job to load DSLs)
           # Create a Job using DSL that loads a remote Jenkinsfile from SCM
           # Define job triggers in the Jenkinsfile
           # Define job paramteres in the Jenkinsfile
           # Run the job once
           # Check job configuration (triggers and parameters will be there)
           # Reload the DSL
           # Check job configuration (triggers and parameters will be lost).
          Julio Morimoto made changes -
          Description Original: h1. Environment

          Jenkins 2.280

          Job DSL Plugin 1.77
          h1. Description

          Given the current (and arguably awkward) behavior of Pipeline jobs (JENKINS-50365), several values, such as triggers and parameters, are only reloaded after the job runs.

          This behavior conflicts with the fact that Job DSL scripts complete overwrite trigger definitions created by the Pipeline script.

          While trying to keep a fully automated job maintenance routine, we load Job DSLs using the JCasC plugin. Our Job DSLs are minimal and define only a directive to load the Jenkinsfile from a remote SCM.

          In practice, we are unable to keep trigger definitions in the Jenkinsfile. Everytime a clean Job DSL is reloaded, all triggers and parameters created by the Jenkinsfile are lost.
          h1. Workaround

          The only workaround we found is to keep triggers defined outside the Jenkinsfile, in the Job DSL.
          h1. Steps to reproduce
           # Install Job DSL Plugin
           # Install JCasC plugin (or use a seed job to load DSLs)
           # Create a Job using DSL that loads a remote Jenkinsfile from SCM
           # Define job triggers in the Jenkinsfile
           # Define job paramteres in the Jenkinsfile
           # Run the job once
           # Check job configuration (triggers and parameters will be there)
           # Reload the DSL
           # Check job configuration (triggers and parameters will be lost).           		New: h1. Environment

          Jenkins 2.280

          Job DSL Plugin 1.77
          h1. Description

          Given the current (and arguably awkward) behavior of Pipeline jobs (JENKINS-50365), several values, such as triggers and parameters, are only reloaded after the job runs.

          This behavior conflicts with the fact that Job DSL scripts complete overwrite trigger definitions created by the Pipeline script.

          While trying to keep a fully automated job maintenance routine, we load Job DSLs using the JCasC plugin. Our Job DSLs are minimal and define only a directive to load the Jenkinsfile from a remote SCM.

          In practice, we are unable to keep trigger and parameterdefinitions in the Jenkinsfile. Everytime a clean Job DSL is reloaded, all triggers and parameters created by the Jenkinsfile are lost.
          h1. Workaround

          The only workaround we found is to keep triggers defined outside the Jenkinsfile, in the Job DSL.
          h1. Steps to reproduce
           # Install Job DSL Plugin
           # Install JCasC plugin (or use a seed job to load DSLs)
           # Create a Job using DSL that loads a remote Jenkinsfile from SCM
           # Define job triggers in the Jenkinsfile
           # Define job paramteres in the Jenkinsfile
           # Run the job once
           # Check job configuration (triggers and parameters will be there)
           # Reload the DSL
           # Check job configuration (triggers and parameters will be lost).
          Julio Morimoto made changes -
          Description Original: h1. Environment

          Jenkins 2.280

          Job DSL Plugin 1.77
          h1. Description

          Given the current (and arguably awkward) behavior of Pipeline jobs (JENKINS-50365), several values, such as triggers and parameters, are only reloaded after the job runs.

          This behavior conflicts with the fact that Job DSL scripts complete overwrite trigger definitions created by the Pipeline script.

          While trying to keep a fully automated job maintenance routine, we load Job DSLs using the JCasC plugin. Our Job DSLs are minimal and define only a directive to load the Jenkinsfile from a remote SCM.

          In practice, we are unable to keep trigger and parameterdefinitions in the Jenkinsfile. Everytime a clean Job DSL is reloaded, all triggers and parameters created by the Jenkinsfile are lost.
          h1. Workaround

          The only workaround we found is to keep triggers defined outside the Jenkinsfile, in the Job DSL.
          h1. Steps to reproduce
           # Install Job DSL Plugin
           # Install JCasC plugin (or use a seed job to load DSLs)
           # Create a Job using DSL that loads a remote Jenkinsfile from SCM
           # Define job triggers in the Jenkinsfile
           # Define job paramteres in the Jenkinsfile
           # Run the job once
           # Check job configuration (triggers and parameters will be there)
           # Reload the DSL
           # Check job configuration (triggers and parameters will be lost).           		New: h1. Environment

          Jenkins 2.280

          Job DSL Plugin 1.77
          h1. Description

          Given the current (and arguably awkward) behavior of Pipeline jobs (JENKINS-50365), several values, such as triggers and parameters, are only reloaded after the job runs.

          This behavior conflicts with the fact that Job DSL scripts complete overwrite trigger definitions created by the Pipeline script.

          While trying to keep a fully automated job maintenance routine, we load Job DSLs using the JCasC plugin. Our Job DSLs are minimal and define only a directive to load the Jenkinsfile from a remote SCM.

          In practice, we are unable to keep trigger and parameter definitions in the Jenkinsfile. Everytime a clean Job DSL is reloaded, all triggers and parameters created by the Jenkinsfile are lost.
          h1. Workaround

          The only workaround we found is to keep triggers defined outside the Jenkinsfile, in the Job DSL.
          h1. Steps to reproduce
           # Install Job DSL Plugin
           # Install JCasC plugin (or use a seed job to load DSLs)
           # Create a Job using DSL that loads a remote Jenkinsfile from SCM
           # Define job triggers in the Jenkinsfile
           # Define job paramteres in the Jenkinsfile
           # Run the job once
           # Check job configuration (triggers and parameters will be there)
           # Reload the DSL
           # Check job configuration (triggers and parameters will be lost).
          Julio Morimoto made changes -
          Description Original: h1. Environment

          Jenkins 2.280

          Job DSL Plugin 1.77
          h1. Description

          Given the current (and arguably awkward) behavior of Pipeline jobs (JENKINS-50365), several values, such as triggers and parameters, are only reloaded after the job runs.

          This behavior conflicts with the fact that Job DSL scripts complete overwrite trigger definitions created by the Pipeline script.

          While trying to keep a fully automated job maintenance routine, we load Job DSLs using the JCasC plugin. Our Job DSLs are minimal and define only a directive to load the Jenkinsfile from a remote SCM.

          In practice, we are unable to keep trigger and parameter definitions in the Jenkinsfile. Everytime a clean Job DSL is reloaded, all triggers and parameters created by the Jenkinsfile are lost.
          h1. Workaround

          The only workaround we found is to keep triggers defined outside the Jenkinsfile, in the Job DSL.
          h1. Steps to reproduce
           # Install Job DSL Plugin
           # Install JCasC plugin (or use a seed job to load DSLs)
           # Create a Job using DSL that loads a remote Jenkinsfile from SCM
           # Define job triggers in the Jenkinsfile
           # Define job paramteres in the Jenkinsfile
           # Run the job once
           # Check job configuration (triggers and parameters will be there)
           # Reload the DSL
           # Check job configuration (triggers and parameters will be lost).           		New: h1. Environment

          Jenkins 2.280

          Job DSL Plugin 1.77
          h1. Description

          Given the current (and arguably awkward) behavior of Pipeline jobs (JENKINS-50365), several values, such as triggers and parameters, are only reloaded after the job runs.

          This behavior conflicts with the fact that Job DSL scripts complete overwrite trigger definitions created by the Pipeline script.

          While trying to keep a fully automated job maintenance routine, we load Job DSLs using the JCasC plugin. Our Job DSLs are minimal and define only a directive to load the Jenkinsfile from a remote SCM.

          In practice, we are unable to keep trigger and parameter definitions in the Jenkinsfile. Everytime a clean Job DSL is reloaded, all triggers and parameters created by the Jenkinsfile are lost.
          h1. Workaround

          The only workaround we found is to keep triggers and parameters defined outside the Jenkinsfile, in the Job DSL.
          h1. Steps to reproduce
           # Install Job DSL Plugin
           # Install JCasC plugin (or use a seed job to load DSLs)
           # Create a Job using DSL that loads a remote Jenkinsfile from SCM
           # Define job triggers in the Jenkinsfile
           # Define job paramteres in the Jenkinsfile
           # Run the job once
           # Check job configuration (triggers and parameters will be there)
           # Reload the DSL
           # Check job configuration (triggers and parameters will be lost).
          Nick Follett made changes -
          Attachment New: image-2021-05-04-13-00-41-893.png [ 54738 ]

          Nick Follett added a comment - - edited

          Our company is suffering from this same issue. We also have pretty bare DSL files which simply point to their Jenkinsfiles, and each Jenkinsfile sets other things like triggering methods.

          When we re-run the DSL Pipeline to update/populate jobs, triggers and other configurations added by the Jenksinfiles are lost. Since we rely on GitHub Pull Request comments to trigger the Pipelines after they are first open, users become unable to reach Jenkins and they become blocked. This creates a large productivity loss for the software engineers because they must close their PR's and open new ones, starting the review process over, since the DSL Pipeline mangled the config.

          We have tried to directly address this by adding the desired triggering to the original DSL, but it is not working with our multibranch Pipeline jobs

          multibranchPipelineJob('Hello_World') {
    triggers {
        issueCommentTrigger {
            commentPattern("test")
        }
    }
    // ...
}

          Error:

          java.lang.ClassCastException: org.jenkinsci.plugins.workflow.multibranch.WorkflowMultiBranchProject cannot be cast to org.jenkinsci.plugins.workflow.job.WorkflowJob

          This error comes as a surprise, because when we visit $JENKINS_URL/plugin/job-dsl/api-viewer/index.html#method/javaposse.jobdsl.dsl.DslFactory.multibranchPipelineJob, which is the introspective API reference specific to our instance, we can clearly see that issueCommentTrigger() is a valid DSL configuration for multibranch Pipelines.

          Version details:

          • Jenkins 2.263.1
          • Job DSL 1.77
          • GitHub Branch Source 2.9.5
          • Pipeline: Multibranch 2.22

          Nick Follett added a comment - - edited Our company is suffering from this same issue. We also have pretty bare DSL files which simply point to their Jenkinsfiles, and each Jenkinsfile sets other things like triggering methods. When we re-run the DSL Pipeline to update/populate jobs, triggers and other configurations added by the Jenksinfiles are lost. Since we rely on GitHub Pull Request comments to trigger the Pipelines after they are first open, users become unable to reach Jenkins and they become blocked. This creates a large productivity loss for the software engineers because they must close their PR's and open new ones, starting the review process over, since the DSL Pipeline mangled the config. We have tried to directly address this by adding the desired triggering to the original DSL, but it is not working with our multibranch Pipeline jobs multibranchPipelineJob( 'Hello_World' ) { triggers { issueCommentTrigger { commentPattern( "test" ) } } // ... } Error: java.lang.ClassCastException: org.jenkinsci.plugins.workflow.multibranch.WorkflowMultiBranchProject cannot be cast to org.jenkinsci.plugins.workflow.job.WorkflowJob This error comes as a surprise, because when we visit $JENKINS_URL/plugin/job-dsl/api-viewer/index.html#method/javaposse.jobdsl.dsl.DslFactory.multibranchPipelineJob, which is the introspective API reference specific to our instance, we can clearly see that  issueCommentTrigger()  is a valid DSL configuration for multibranch Pipelines. Version details: Jenkins 2.263.1 Job DSL 1.77 GitHub Branch Source 2.9.5 Pipeline: Multibranch 2.22
          Julio Morimoto made changes -
          Description Original: h1. Environment

          Jenkins 2.280

          Job DSL Plugin 1.77
          h1. Description

          Given the current (and arguably awkward) behavior of Pipeline jobs (JENKINS-50365), several values, such as triggers and parameters, are only reloaded after the job runs.

          This behavior conflicts with the fact that Job DSL scripts complete overwrite trigger definitions created by the Pipeline script.

          While trying to keep a fully automated job maintenance routine, we load Job DSLs using the JCasC plugin. Our Job DSLs are minimal and define only a directive to load the Jenkinsfile from a remote SCM.

          In practice, we are unable to keep trigger and parameter definitions in the Jenkinsfile. Everytime a clean Job DSL is reloaded, all triggers and parameters created by the Jenkinsfile are lost.
          h1. Workaround

          The only workaround we found is to keep triggers and parameters defined outside the Jenkinsfile, in the Job DSL.
          h1. Steps to reproduce
           # Install Job DSL Plugin
           # Install JCasC plugin (or use a seed job to load DSLs)
           # Create a Job using DSL that loads a remote Jenkinsfile from SCM
           # Define job triggers in the Jenkinsfile
           # Define job paramteres in the Jenkinsfile
           # Run the job once
           # Check job configuration (triggers and parameters will be there)
           # Reload the DSL
           # Check job configuration (triggers and parameters will be lost).           		New: h1. Environment

          Jenkins 2.280

          Job DSL Plugin 1.77
          h1. Description

          Given the current (and arguably awkward) behavior of Pipeline jobs (JENKINS-50365), several values, such as triggers and parameters, are only reloaded after the job runs.

          This behavior conflicts with the fact that Job DSL scripts completely overwrite trigger definitions created by the Pipeline script.

          While trying to keep a fully automated job maintenance routine, we load Job DSLs using the JCasC plugin. Our Job DSLs are minimal and define only a directive to load the Jenkinsfile from a remote SCM.

          In practice, we are unable to keep trigger and parameter definitions in the Jenkinsfile. Everytime a clean Job DSL is reloaded, all triggers and parameters created by the Jenkinsfile are lost.
          h1. Workaround

          The only workaround we found is to keep triggers and parameters defined outside the Jenkinsfile, in the Job DSL.
          h1. Steps to reproduce
           # Install Job DSL Plugin
           # Install JCasC plugin (or use a seed job to load DSLs)
           # Create a Job using DSL that loads a remote Jenkinsfile from SCM
           # Define job triggers in the Jenkinsfile
           # Define job paramteres in the Jenkinsfile
           # Run the job once
           # Check job configuration (triggers and parameters will be there)
           # Reload the DSL
           # Check job configuration (triggers and parameters will be lost).

            jamietanna Jamie Tanna
            juliohm Julio Morimoto
            Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: