You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're using Sirene of Shame connected to the VSTS and monitoring few projects builds.
When one build (project A) is in failed state, sirene is blinking for the failed build as expected. But, if after that someone has triggered next build (project B), sirene is blinking for the running build as expected as well. If the second build is successfull, sirene is not blinkinig anymore even if the first build for project A is still failed.
It would be nice to remain the Sirene behavior for the failed build if at least one build is in failed state.
The text was updated successfully, but these errors were encountered:
That's a great point! I've mostly only ever watched a small numbers of builds, but I can imagine with many builds the value of the siren would go down. To do it right is a tricky concurrency problem. But perhaps an easy first step is just to remember and then restore the state of the siren when a build is triggered.
We're using Sirene of Shame connected to the VSTS and monitoring few projects builds.
When one build (project A) is in failed state, sirene is blinking for the failed build as expected. But, if after that someone has triggered next build (project B), sirene is blinking for the running build as expected as well. If the second build is successfull, sirene is not blinkinig anymore even if the first build for project A is still failed.
It would be nice to remain the Sirene behavior for the failed build if at least one build is in failed state.
The text was updated successfully, but these errors were encountered: