[JIRA] (JENKINS-42785) Parameterized Pipeline Projects have their Build Triggers unset after each build

1 view
Skip to first unread message

keithzg@gmail.com (JIRA)

unread,
Mar 14, 2017, 10:12:02 PM3/14/17
to jenkinsc...@googlegroups.com
Keith Zubot-Gephart created an issue
 
Jenkins / Bug JENKINS-42785
Parameterized Pipeline Projects have their Build Triggers unset after each build
Issue Type: Bug Bug
Assignee: Unassigned
Components: pipeline
Created: 2017/Mar/15 2:11 AM
Environment: Windows, Jenkins 2.50
Labels: parameterized
Priority: Minor Minor
Reporter: Keith Zubot-Gephart

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'
         }
{{      }}}
   }
}

Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
Atlassian logo

keithzg@gmail.com (JIRA)

unread,
Mar 14, 2017, 10:12:02 PM3/14/17
to jenkinsc...@googlegroups.com
Keith Zubot-Gephart updated an issue
Change By: Keith Zubot-Gephart
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'}}
{{         }}}
{{             } }}
{{   }}}
{{}}}

keithzg@gmail.com (JIRA)

unread,
Mar 14, 2017, 10:13:03 PM3/14/17
to jenkinsc...@googlegroups.com

keithzg@gmail.com (JIRA)

unread,
Mar 14, 2017, 10:52:01 PM3/14/17
to jenkinsc...@googlegroups.com
Keith Zubot-Gephart updated an issue
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 \{ code:java } }
pipeline { {
   agent any }}
{{    parameters \ { }}
{{       string(name: 'requested', defaultValue: 'all', description: 'Which stages should be run?') }}
{{    } }}
{{    stages \ { }}
{{       stage('stage1') \ { }}
{{          steps \ { }}
{{             echo 'Running stage 1' }}
{{          } }}
     
      }
{{    } }}
} { { code } }}

 

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

{ {pipeline \{ code:java } }
pipeline { {
   agent any }}
{{    stages \ { }}
{{       stage('stage1') \ { }}
{{          steps \ { }}
{{             echo 'Running stage 1' }}
{{          } }}
     
      }
{{    } }}
} { { code } }}

chris@orr.me.uk (JIRA)

unread,
Mar 15, 2017, 6:47:01 AM3/15/17
to jenkinsc...@googlegroups.com
Christopher Orr commented on Bug JENKINS-42785
 
Re: Parameterized Pipeline Projects have their Build Triggers unset after each build

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.

keithzg@gmail.com (JIRA)

unread,
Mar 21, 2017, 4:33:02 PM3/21/17
to jenkinsc...@googlegroups.com

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.

keithzg@gmail.com (JIRA)

unread,
Mar 21, 2017, 4:39:01 PM3/21/17
to jenkinsc...@googlegroups.com
Keith Zubot-Gephart edited a comment on Bug JENKINS-42785
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.

andrew.bayer@gmail.com (JIRA)

unread,
Mar 28, 2017, 6:31:02 PM3/28/17
to jenkinsc...@googlegroups.com
Andrew Bayer updated an issue
 
Change By: Andrew Bayer
Component/s: pipeline-model-definition-plugin
Component/s: pipeline

andrew.bayer@gmail.com (JIRA)

unread,
Mar 28, 2017, 6:39:03 PM3/28/17
to jenkinsc...@googlegroups.com
Andrew Bayer commented on Bug JENKINS-42785
 
Re: Parameterized Pipeline Projects have their Build Triggers unset after each build

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

andrew.bayer@gmail.com (JIRA)

unread,
Mar 28, 2017, 6:39:03 PM3/28/17
to jenkinsc...@googlegroups.com

andrew.bayer@gmail.com (JIRA)

unread,
Mar 28, 2017, 6:39:03 PM3/28/17
to jenkinsc...@googlegroups.com

andrew.bayer@gmail.com (JIRA)

unread,
Mar 28, 2017, 6:39:03 PM3/28/17
to jenkinsc...@googlegroups.com

keithzg@gmail.com (JIRA)

unread,
Mar 28, 2017, 8:23:02 PM3/28/17
to jenkinsc...@googlegroups.com
Keith Zubot-Gephart commented on Story JENKINS-42785
 
Re: Parameterized Pipeline Projects have their Build Triggers unset after each build

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

bitwiseman@gmail.com (JIRA)

unread,
Oct 22, 2019, 11:24:50 PM10/22/19
to jenkinsc...@googlegroups.com
Liam Newman closed an issue as Duplicate
 

Bulk closing resolved issues.

Change By: Liam Newman
Status: Resolved Closed
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo
Reply all
Reply to author
Forward
0 new messages