-
Bug
-
Resolution: Unresolved
-
Minor
-
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
- 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).
[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 ] |
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). |
| Assignee | Original: Daniel Spilker [ daspilker ] | New: Jamie Tanna [ jamietanna ] |