[JIRA] (JENKINS-40898) Declarative should provide an easy way to disable/enable some steps in an PR context or not

2 views
Skip to first unread message

batmat@batmat.net (JIRA)

unread,
Jan 9, 2017, 6:29:01 PM1/9/17
to jenkinsc...@googlegroups.com
Baptiste Mathus updated an issue
 
Jenkins / Bug JENKINS-40898
Declarative should provide an easy way to disable/enable some steps in an PR context or not
Change By: Baptiste Mathus
Summary: Declarative should provide an easy way to disable/enable some steps in an PR context or not
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
Atlassian logo

pwolf@cloudbees.com (JIRA)

unread,
Jan 10, 2017, 11:27:02 AM1/10/17
to jenkinsc...@googlegroups.com
Patrick Wolf commented on Bug JENKINS-40898
 
Re: Declarative should provide an easy way to disable/enable some steps in an PR context or not

How would you know what a 'notification' is? You would have to maintain a static list of all possible notification mechanisms to implement something like that.

Pull Request might have to just be a specific branch pattern, otherwise it might not be able to be generalized across different scm-providers.

batmat@batmat.net (JIRA)

unread,
Jan 12, 2017, 8:36:02 AM1/12/17
to jenkinsc...@googlegroups.com

Current workaround:

failure {
    script {
        if (!env.BRANCH_NAME.startsWith('PR-')) {
            mail to: NOTIFICATION_TARGET, subject: "FAILURE: ${currentBuild.fullDisplayName}", body: "Boo, we failed. $BUILD_URL"
        }
    }
}

I agree my proposal in the description is very weak and limited. Must give it more thoughts.

batmat@batmat.net (JIRA)

unread,
Jan 12, 2017, 8:47:01 AM1/12/17
to jenkinsc...@googlegroups.com
Baptiste Mathus updated an issue
Change By: Baptiste Mathus
When writing a Jenkinsfile, if you have email notifications, or notifications in general, this probably does not make sense to send those when building a PR. Same goes for actual deployments or touching real environments by any mean.

PR are reviewed through GitHub, have a build status there, and so on. So by default, sending emails to maintainers creates unnecessary noise.

Maybe this be globally enabled/disabled by default though the new {{options}} block.

Like:

{code:java}
options {
    notifyOnPullRequest    notifyOnChangeRequest = true // I would argue that we should be opinionated and put it with a default of false
}
{code}
And possibly be overridable per step, like:

{code:java}
 notOnPR notOnChangeRequest { // PR on GitHub & Bitbucket, patchset on Gerrit, Review Request in ReviewBoard...
   mail to: NOTIFICATION_TARGET, subject:"FAILURE: ${currentBuild.fullDisplayName}", body: "Boo, we failed"
}
{code}

 For when and usual stage deactivations:

{code}
when {
   onChangeRequest
}
{code}

 WDYT?

Thanks!

batmat@batmat.net (JIRA)

unread,
Jan 12, 2017, 8:49:01 AM1/12/17
to jenkinsc...@googlegroups.com
Baptiste Mathus updated an issue
When writing a Jenkinsfile, if you have email notifications, or notifications in general, this probably does not make sense to send those when building a PR. Same goes for actual deployments or touching real environments by any mean.

PR are reviewed through GitHub, have a build status there, and so on. So by default, sending emails to maintainers creates unnecessary noise.

Maybe this be globally enabled/disabled by default though the new {{options}} block.

Like:

{code:java}
options {
   notifyOnChangeRequest = true // I would argue that we should be opinionated and put it with a default of false
}
{code}

And possibly be overridable per step, like:

{code:java}
notOnChangeRequest { // PR on GitHub & Bitbucket, patchset on Gerrit, Review Request in ReviewBoard...
   mail to: NOTIFICATION_TARGET, subject:"FAILURE: ${currentBuild.fullDisplayName}", body: "Boo, we failed"
}
{code}

For when and usual stage deactivations:

{code}
when {
   onChangeRequest     branch CHANGE_REQUEST
}
{code}

WDYT?

Thanks!

batmat@batmat.net (JIRA)

unread,
Jan 12, 2017, 8:50:01 AM1/12/17
to jenkinsc...@googlegroups.com
Baptiste Mathus updated an issue
When writing a Jenkinsfile, if you have email notifications, or notifications in general, this probably does not make sense to send those when building a PR. Same goes for actual deployments or touching real environments by any mean.

PR are reviewed through GitHub, have a build status there, and so on. So by default, sending emails to maintainers creates unnecessary noise.

Maybe this be globally enabled/disabled by default though the new {{options}} block.

Like:

{code:java}
options {
   notifyOnChangeRequest = true // I would argue that we should be opinionated and put it with a default of false
}
{code}

And possibly be overridable per step, like:

{code:java}
notOnChangeRequest { // PR on GitHub & Bitbucket, patchset on Gerrit, Review Request in ReviewBoard...
   mail to: NOTIFICATION_TARGET, subject:    sh " FAILURE: ${currentBuild deploy-to-production . fullDisplayName} sh " , body: "Boo, we failed"
}
{code}

For when and usual stage deactivations:

{code}
when {
    branch CHANGE_REQUEST
}
{code}

WDYT?

Thanks!

batmat@batmat.net (JIRA)

unread,
Jan 12, 2017, 9:26:01 AM1/12/17
to jenkinsc...@googlegroups.com
 
Re: Declarative should provide an easy way to disable/enable some steps in an PR context or not

Also:

Hmmm. So the when condition on stages is probably what you need, but you'd have to put your notification(s) in a separate stage since when controls whether the entire stage executes. I'm also not sure how you'd determine if you're in a PR context. =)

As discussed on IRC, won't work because if the pipeline fails in early stages, then the stage with those notifications won't be reached anyway, hence the notifications never sent.

pwolf@cloudbees.com (JIRA)

unread,
Jan 12, 2017, 10:24:01 AM1/12/17
to jenkinsc...@googlegroups.com

if someone creates a Pipeline step called notOnChangeRequest that will wrap all steps that shouldn't run when it is a PR build that will work in Declarative without needing script. A step that simple could also be implemented in a Shared Library.

Having a global option of notifyOnChangeRequest means we have to maintain a static list of notifying steps to blacklist.

pwolf@cloudbees.com (JIRA)

unread,
Jan 12, 2017, 10:26:05 AM1/12/17
to jenkinsc...@googlegroups.com
Patrick Wolf edited a comment on Bug JENKINS-40898
if someone creates a A Pipeline step called {{notOnChangeRequest}} or {{skipOnPR}} that will wrap all steps that shouldn't run when it is a to skip in PR build that will would work in Declarative without needing {{script}}. It would also be available to use in Scripted Pipeline. A step that simple could also be implemented in a Shared Library.


Having a global option of {{notifyOnChangeRequest}} means we have to maintain a static list of notifying steps to blacklist.

andrew.bayer@gmail.com (JIRA)

unread,
Feb 27, 2017, 4:37:04 PM2/27/17
to jenkinsc...@googlegroups.com
Andrew Bayer resolved as Fixed
 

I think when branch does the trick here?
Change By: Andrew Bayer
Status: Open Resolved
Resolution: Fixed

batmat@batmat.net (JIRA)

unread,
Mar 8, 2017, 4:31:01 PM3/8/17
to jenkinsc...@googlegroups.com
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
Atlassian logo

andrew.bayer@gmail.com (JIRA)

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

No - open a ticket for that - I know someone else requested something along those lines.

pwolf@cloudbees.com (JIRA)

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

Could also have a stage called "notifications" at the end of your pipeline.

batmat@batmat.net (JIRA)

unread,
Mar 8, 2017, 5:13:02 PM3/8/17
to jenkinsc...@googlegroups.com

batmat@batmat.net (JIRA)

unread,
Mar 8, 2017, 5:14:01 PM3/8/17
to jenkinsc...@googlegroups.com

OMG, crappy cross comment linking. I was referring to my previous comment about this:

As discussed on IRC, won't work because if the pipeline fails in early stages, then the stage with those notifications won't be reached anyway, hence the notifications never sent.

batmat@batmat.net (JIRA)

unread,
Mar 11, 2017, 9:36:03 AM3/11/17
to jenkinsc...@googlegroups.com

bitwiseman@gmail.com (JIRA)

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

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