-
Bug
-
Resolution: Fixed
-
Minor
-
None
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:
options {
notifyOnChangeRequest = true // I would argue that we should be opinionated and put it with a default of false
}
And possibly be overridable per step, like:
notOnChangeRequest { // PR on GitHub & Bitbucket, patchset on Gerrit, Review Request in ReviewBoard...
sh "deploy-to-production.sh"
}
For when and usual stage deactivations:
when {
branch CHANGE_REQUEST
}
WDYT?
Thanks!
- relates to
-
JENKINS-42688 Provide a way to enable a post/* to run only under some context
-
- In Progress
-
- links to
[JENKINS-40898] Declarative should provide an easy way to disable/enable some steps in an PR context or not
| Summary | Original: Declarative should provide an easy to disable/enable some steps in an PR context or not | New: 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.
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.
| Description |
Original:
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. 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 = 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 { mail to: NOTIFICATION_TARGET, subject:"FAILURE: ${currentBuild.fullDisplayName}", body: "Boo, we failed" } {code} WDYT? Thanks! |
New:
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 } {code} WDYT? Thanks! |
| Description |
Original:
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 } {code} WDYT? Thanks! |
New:
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 { branch CHANGE_REQUEST } {code} WDYT? Thanks! |
| Description |
Original:
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 { branch CHANGE_REQUEST } {code} WDYT? Thanks! |
New:
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... sh "deploy-to-production.sh" } {code} For when and usual stage deactivations: {code} when { branch CHANGE_REQUEST } {code} WDYT? Thanks! |
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.
A Pipeline step called notOnChangeRequest or skipOnPR that will wrap steps to skip in PR build 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.
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. =)