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

Parameterized Pipeline Projects have their Build Triggers unset after each build

    Details

    • Similar Issues:

      Description

      At least as of a few updates ago (I swear this used to work) I've noticed all the Pipeline projects I've set up only trigger once, and then I have to go in and set the build triggers again because all the triggers have become unset.

      This of course makes the pipeline projects I've set up fairly unhelpful, since this thus requires manual intervention for every single run.

      I've narrowed this down to parameters. If I have a "Pipeline script" or specify a Jenkinsfile with "Pipeline script from SCM", any build (whether triggered by one of the Build Triggers or manually) results in the Build Triggers becoming unset.

      Specifically, the following settings, if set before the build is run, become uncheckmarked:

      • Build after other projects are built
      • Build periodically
      • GitHub hook trigger for GITScm polling
      • Poll SCM

      Interestingly, although they are also under the Build Triggers heading, "Quiet period" and "Trigger builds remotely (e.g., from scripts)" remain set.

      Here is an example Pipeline script that reproduces this problem for me:

      pipeline {
          agent any
          parameters {
             string(name: 'requested', defaultValue: 'all', description: 'Which stages should be run?')
          }
          stages {
             stage('stage1') {
                steps {
                   echo 'Running stage 1'
                }
             }
          }
       }

       

      Conversely, the following doesn't lose the scheduling settings:

      pipeline {
          agent any
          stages {
             stage('stage1') {
                steps {
                   echo 'Running stage 1'
                }
             }
          }
       }

        Attachments

          Issue Links

            Activity

            Hide
            orrc Christopher Orr added a comment -

            Is this specific to Declarative Pipelines, i.e. in the style you've written above, starting with pipeline {?

            Just wondering whether this should be reassigned to the pipeline-model-definition component.

            Show
            orrc Christopher Orr added a comment - Is this specific to Declarative Pipelines, i.e. in the style you've written above, starting with pipeline { ? Just wondering whether this should be reassigned to the pipeline-model-definition component.
            Hide
            keithzg Keith Zubot-Gephart added a comment - - edited

            Apologies for the delayed reply, it's been unexpectedly busy at work. Unfortunately, I don't actually know how to write a non-declarative pipeline script, certainly not one that's parameterized, and I've had a hard time trying to find or work out such a script.

            Edit: Looking at https://jenkins.io/doc/book/pipeline/syntax/#parameters it claims 

            Only once, inside the pipeline block.

            which would seem to preclude using it outside of `pipeline {`? If not, certainly I can't discern any more, alas.

            Show
            keithzg Keith Zubot-Gephart added a comment - - edited Apologies for the delayed reply, it's been unexpectedly busy at work. Unfortunately, I don't actually know how to write a  non -declarative pipeline script, certainly not one that's parameterized, and I've had a hard time trying to find or work out such a script. Edit: Looking at https://jenkins.io/doc/book/pipeline/syntax/#parameters  it claims  Only once, inside the pipeline block. which would seem to preclude using it outside of `pipeline {`? If not, certainly I can't discern any more, alas.
            Hide
            abayer Andrew Bayer added a comment -

            So...this brings up a good question! The root cause here is that job parameters, triggers and other misc job properties are all set in Pipeline (including Declarative, albeit behind the scenes) with the properties step...which overwrites whatever was previously in the job properties/triggers/parameters. So if you have parameters in your Declarative Pipeline but not triggers, your triggers are always going to get wiped out. The quiet period and remote trigger bit are technically not part of the triggers which is why they stay set. Is weird, I know.

            So a workaround for this for you would be to use this as your Jenkinsfile:

            pipeline {
                agent any
                parameters {
                   string(name: 'requested', defaultValue: 'all', description: 'Which stages should be run?')
                }
                triggers {
                    cron('@daily')
                    pollSCM('@hourly')
                    githubPush()
                    upstream(threshold: hudson.model.Result.SUCCESS, upstreamProjects: "some-project,some-other-project")
                }
                stages {
                   stage('stage1') {
                      steps {
                         echo 'Running stage 1'
                      }
                   }
                }
             }

            I'm not 100% sure upstream will work right - it should but I honestly can't remember for sure. But the other three certainly will.

            The question this all raises is whether Declarative should allow the UI-configured job properties/parameters/triggers to persist if they're not explicitly overridden. I'm not sure yet, which is why I'm leaving this open. =)

            Show
            abayer Andrew Bayer added a comment - So...this brings up a good question! The root cause here is that job parameters, triggers and other misc job properties are all set in Pipeline (including Declarative, albeit behind the scenes) with the properties step...which overwrites whatever was previously in the job properties/triggers/parameters. So if you have parameters in your Declarative Pipeline but not triggers , your triggers are always going to get wiped out. The quiet period and remote trigger bit are technically not part of the triggers which is why they stay set. Is weird, I know. So a workaround for this for you would be to use this as your Jenkinsfile : pipeline {    agent any    parameters {       string(name: 'requested' , defaultValue: 'all' , description: 'Which stages should be run?' )    } triggers { cron( '@daily' ) pollSCM( '@hourly' ) githubPush() upstream(threshold: hudson.model.Result.SUCCESS, upstreamProjects: "some-project,some-other-project" ) }    stages {       stage( 'stage1' ) {          steps {             echo 'Running stage 1'          }       }    } } I'm not 100% sure upstream will work right - it should but I honestly can't remember for sure. But the other three certainly will. The question this all raises is whether Declarative should allow the UI-configured job properties/parameters/triggers to persist if they're not explicitly overridden. I'm not sure yet, which is why I'm leaving this open. =)
            Hide
            keithzg Keith Zubot-Gephart added a comment -

            Fair enough! Well for my part at least, I can confirm adding a triggers{} section solved the problem, so many thanks

            Show
            keithzg Keith Zubot-Gephart added a comment - Fair enough! Well for my part at least, I can confirm adding a triggers{} section solved the problem, so many thanks
            Hide
            abayer Andrew Bayer added a comment -

            Ok, been thinking on this and I think we have to go with overwriting properties/triggers/parameters if they're not explicitly set in the Jenkinsfile. There's no way I can figure out to tell the difference between a property/trigger/parameter defined in the UI and one defined in the previous version of the Jenkinsfile but not in the current one, and we should definitely be removing anything in the latter scenario.

            Show
            abayer Andrew Bayer added a comment - Ok, been thinking on this and I think we have to go with overwriting properties/triggers/parameters if they're not explicitly set in the Jenkinsfile. There's no way I can figure out to tell the difference between a property/trigger/parameter defined in the UI and one defined in the previous version of the Jenkinsfile but not in the current one, and we should definitely be removing anything in the latter scenario.
            Hide
            michaelneale Michael Neale added a comment -

            It makes no sense to have both UI config and Jenkinsfile config is they fight and can't get along. 

            Ideally it would error or warn if the UI properties/triggers are "set" and Jenkinsfile is also "set". Or else remove it from the UI. Or the Jenkinsfile. as it is - not very nice. 

            Show
            michaelneale Michael Neale added a comment - It makes no sense to have both UI config and Jenkinsfile config is they fight and can't get along.  Ideally it would error or warn if the UI properties/triggers are "set" and Jenkinsfile is also "set". Or else remove it from the UI. Or the Jenkinsfile. as it is - not very nice. 
            Hide
            bitwiseman Liam Newman added a comment -

            Bulk closing resolved issues.

            Show
            bitwiseman Liam Newman added a comment - Bulk closing resolved issues.

              People

              • Assignee:
                abayer Andrew Bayer
                Reporter:
                keithzg Keith Zubot-Gephart
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: