-
Improvement
-
Resolution: Fixed
-
Minor
-
None
post/changed is called for both X->SUCCESS, or SUCCESS->X.
X being typically failure or unstable.
As a user, I would like to have a very straightforward way to express that I'm only interested in the X->SUCCESS direction, because actually the SUCCESS->X is already covered by post/unstable or post/failure blocks.
My use case is the following: I want to send an email for failures, unstable, and back to success. For the reason explained above, I don't want to send a notification when the status changes from success to something else, because then I would send two notifications instead for one actual event. And it would lower the signal/noise ratio.
I think it could be fullfilled like:
post {
// we could also add previousState below, btw. But in that case it would
// force me to express all the possible previous statuses, which I don't
// care about here
changed(newState: SUCCESS) {
mail to: NOTIFICATION_TARGET, subject: "BACK TO SUCCESS! YAY!: .......
}
failure {
mail to: NOTIFICATION_TARGET, subject: "FAILURE: .......
}
// ...
}
Thanks!
- relates to
-
-
- In Progress
-
- links to
[JENKINS-41060] post/changed should make it easy to restrict on the new/previous status
| Description |
Original:
{{post/changed}} is called for both X->SUCCESS, or SUCCESS->X. X being typically {{failure}} or {{unstable}}. As a user, I would like to have a very straightforward way to express that I'm only interested in the X->SUCCESS _direction_, because actually the {{SUCCESS->X}} is already covered by {{post/unstable}} or {{post/failure}} blocks. My use case is the following: I want to send an email for failures, unstable, and back to success. For the reason explained above, I don't want to send a notification when the status changes from success to something else, because then I would send two notifications instead for one actual event. And it would lower the _signal/noise_ ratio. I think it could be fullfilled like: {code} post { // we could also add previousState below, btw. But in that case it would // force me to express all the possible previous statuses, which I don't // care about here changed(newState: SUCCESS) { mail to: NOTIFICATION_TARGET, subject: "FAILURE: ....... } failure { mail to: NOTIFICATION_TARGET, subject: "FAILURE: ....... } // ... } {code} Thanks! |
New:
{{post/changed}} is called for both X->SUCCESS, or SUCCESS->X. X being typically {{failure}} or {{unstable}}. As a user, I would like to have a very straightforward way to express that I'm only interested in the X->SUCCESS _direction_, because actually the {{SUCCESS->X}} is already covered by {{post/unstable}} or {{post/failure}} blocks. My use case is the following: I want to send an email for failures, unstable, and back to success. For the reason explained above, I don't want to send a notification when the status changes from success to something else, because then I would send two notifications instead for one actual event. And it would lower the _signal/noise_ ratio. I think it could be fullfilled like: {code} post { // we could also add previousState below, btw. But in that case it would // force me to express all the possible previous statuses, which I don't // care about here changed(newState: SUCCESS) { mail to: NOTIFICATION_TARGET, subject: "BACK TO SUCCESS! YAY!: ....... } failure { mail to: NOTIFICATION_TARGET, subject: "FAILURE: ....... } // ... } {code} Thanks! |
| Summary | Original: post/changed should make it easy to restrict on the previous status | New: post/changed should make it easy to restrict on the new/previous status |
Just checked, and it's wee a bit more convoluted. As I forgot, currentBuild.result is only set on FAILURE, hence it is actually:
post {
changed {
script {
if (currentBuild.result == null) {
mail to: NOTIFICATION_TARGET, subject: "BACK TO SUCCESS: ${currentBuild.fullDisplayName}", body: "Yay! $BUILD_URL"
}
}
}
}
| Link | New: This issue relates to JENKINS-42688 [ JENKINS-42688 ] |
| Epic Link |
New:
|
| Status | Original: Open [ 1 ] | New: In Progress [ 3 ] |
| Status | Original: In Progress [ 3 ] | New: In Review [ 10005 ] |
PR up at https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/248 to add new fixed and regression post conditions. Not as general purpose as what you originally proposed but a lot better fit with the syntax and parsing. =)
| Remote Link | New: This issue links to "PR #248 (Web Link)" [ 20170 ] |
Though I didn't try it yet, I suspect the current workaround would be:
post { changed { script { if(currentBuild.result == "SUCCESS) { // pseudo-code, didn't check the exact syntax mail to: NOTIFICATION_TARGET, subject: "BACK TO SUCCESS! : ....... } } } }