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

    • 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).

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

          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

          Carl Dorbeus added a comment -

          +1

          Carl Dorbeus added a comment - +1

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

              Created:
              Updated: