-
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 |
| 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 ] |
| Remote Link | New: This issue links to "PR #248 (Web Link)" [ 20170 ] |
| Resolution | New: Fixed [ 1 ] | |
| Status | Original: In Review [ 10005 ] | New: Resolved [ 5 ] |
| Status | Original: Resolved [ 5 ] | New: Closed [ 6 ] |