Change Details

Various installs have requested Herald support for Harbormaster builds, particular build failures. This is reasonable, but if possible I'd like to identify the group of most common use cases and provide tailored tools for those use cases //before// providing Herald rules. Without this, installs may end up with a large number of complicated Herald rules when a simpler mechanism (like subscriptions) could replace most of them. --- **Use Cases** From T10260. This task has significant similar earlier discussion. > I see this as being important for long running tests that should alert someone as soon as a failure is detected as I can't depend on all responsible parties to check the harbormaster application hourly. I think this is now moot, since build failures have alerted the most likely responsible users -- owners of related objects (commits and revisions) -- for a long time. > also a group of users who are actively maintaining [the test] incase they need to coordinate work. This could be resolved with a "Notify Users When This Plan Fails" field. > My users want to send an email to the entire team when a build fails. This could also be resolved with a "Notify Users When This Plan Fails" field. > My management would like to flag Commits for Audit if they either don't have an accepted Revision (already have this setup in Herald) OR they have failed Harbormaster Builds. This isn't really a related use case and was addressed in D20470. --- From T5491: > At minimum I could use to this to notify IRC on a CI build failure This is an appropriate use case for Herald or Webhooks, and doesn't make sense as a standalone mechanism. --- See PHI901: Harbormaster notification rules aren't currently very flexible, and rules like "Notify on build failure: ..." and/or Herald support for something like "When build status changes to failed" would help address some reasonable use cases. This use case would be covered by "Notify Users When This Plan Fails". --- - See also T13088.

Various installs have requested Herald support for Harbormaster builds, particular build failures. This is reasonable, but if possible I'd like to identify the group of most common use cases and provide tailored tools for those use cases //before// providing Herald rules. Without this, installs may end up with a large number of complicated Herald rules when a simpler mechanism (like subscriptions) could replace most of them. --- **Use Cases** From T10260. This task has significant similar earlier discussion. > I see this as being important for long running tests that should alert someone as soon as a failure is detected as I can't depend on all responsible parties to check the harbormaster application hourly. I think this is now moot, since build failures have alerted the most likely responsible users -- owners of related objects (commits and revisions) -- for a long time. > also a group of users who are actively maintaining [the test] incase they need to coordinate work. This could be resolved with a "Notify Users When This Plan Fails" field. > My users want to send an email to the entire team when a build fails. This could also be resolved with a "Notify Users When This Plan Fails" field. > My management would like to flag Commits for Audit if they either don't have an accepted Revision (already have this setup in Herald) OR they have failed Harbormaster Builds. This isn't really a related use case and was addressed in D20470. --- From T5491: > At minimum I could use to this to notify IRC on a CI build failure This is an appropriate use case for Herald or Webhooks, and doesn't make sense as a standalone mechanism. --- See PHI901: Harbormaster notification rules aren't currently very flexible, and rules like "Notify on build failure: ..." and/or Herald support for something like "When build status changes to failed" would help address some reasonable use cases. This particular case wants to notify when builds //on a particular branch// break. This use case would //possibly// be covered by "Notify Users When This Plan Fails", but might require using two similar build plans (one for master, one for other branches). See PHI1994. An install with a large number of similar builds would like to use a single piece of configuration to support aborting all of them. This is appropriate for webhooks. See PHI1414. The install never got back to me with use cases. --- - See also T13088.

Various installs have requested Herald support for Harbormaster builds, particular build failures. This is reasonable, but if possible I'd like to identify the group of most common use cases and provide tailored tools for those use cases //before// providing Herald rules. Without this, installs may end up with a large number of complicated Herald rules when a simpler mechanism (like subscriptions) could replace most of them. --- **Use Cases** From T10260. This task has significant similar earlier discussion. > I see this as being important for long running tests that should alert someone as soon as a failure is detected as I can't depend on all responsible parties to check the harbormaster application hourly. I think this is now moot, since build failures have alerted the most likely responsible users -- owners of related objects (commits and revisions) -- for a long time. > also a group of users who are actively maintaining [the test] incase they need to coordinate work. This could be resolved with a "Notify Users When This Plan Fails" field. > My users want to send an email to the entire team when a build fails. This could also be resolved with a "Notify Users When This Plan Fails" field. > My management would like to flag Commits for Audit if they either don't have an accepted Revision (already have this setup in Herald) OR they have failed Harbormaster Builds. This isn't really a related use case and was addressed in D20470. --- From T5491: > At minimum I could use to this to notify IRC on a CI build failure This is an appropriate use case for Herald or Webhooks, and doesn't make sense as a standalone mechanism. --- See PHI901: Harbormaster notification rules aren't currently very flexible, and rules like "Notify on build failure: ..." and/or Herald support for something like "When build status changes to failed" would help address some reasonable use cases. This particular case wants to notify when builds //on a particular branch// break. This use case would //possibly// be covered by "Notify Users When This Plan Fails". , but might require using two similar build plans (one for master, one for other branches). See PHI1994. An install with a large number of similar builds would like to use a single piece of configuration to support aborting all of them. This is appropriate for webhooks. See PHI1414. The install never got back to me with use cases. --- - See also T13088.