Page MenuHomePhabricator

Support Herald rules for Harbormaster Builds
Open, NormalPublic

Description

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.


Event Timeline

epriestley triaged this task as Normal priority.Feb 19 2021, 4:22 AM
epriestley created this task.
epriestley updated the task description. (Show Details)

A minimal implementation here is probably:

  1. When a Build fails, notify subscribers to the Build Plan.
  2. Support Herald for Builds.

The issues I can come up with for (1) are that:

  • It prevents you from keeping track of changes to a build plan without also getting inundated with build notifications.
  • It's not super intuitive, and it's sort of arbitrary that failing builds (but not passing builds) would notify.

So a slightly less minimal implementation is probably:

  1. Add a "Notify Users on Failure" field to Build Plans.
  2. Support Herald for Builds.

I think this solves both of the issues at a modest complexity cost.

I dug up another one of these in PHI1439, but there is a lot of text in that issue that I haven't re-read yet.