Page MenuHomePhabricator

Merge Harbormaster BuildCommand into BuildMessage
Open, WishlistPublic

Description

See T13054. After those changes:

Buildables stuck in "building" despite an aborted build should get a best-effort migration if nothing else moots that (see also T10746).

Harbormaster has BuildCommand and BuildMessage. These are basically the same table. BuildCommand is sent to Build. BuildMessage is sent to BuildTarget and Buildable. These should probably just be the same table, and Build should be a valid receiver for BuildMessage.

If you arc diff --only, the buildable never leaves PENDING. A likely fix for this is to make arc call harbormaster.sendmessage(<buildablePHID>, "build") after it uploads lint and unit results if it's not going to create a revision. Currently, this method can not send messages to a Buildable and probably can't send a "build" message.


See PHI1380, which wants API access to the restart command. (This issue has nothing to do with Harbormaster, not sure what the original issue was.)

See also PHI1390, which is adjacent.

See also PHI1966, which wants access to the build command.

See also PHI614, which wants build/restart commands (approximately).

Event Timeline

epriestley triaged this task as Wishlist priority.Feb 12 2018, 11:01 PM
epriestley created this task.

D19269 makes Harbormaster objects destructible. I've made Build destroy BuildMessage (which it doesn't receive, so this never destroys anything) but not BuildCommand (which it does receive), so that when this change is made (and it starts receiving BuildMessage instead of BuildCommand) things will just work. Until then, BuildCommand objects are technically left hanging, but destroying builds is exceptionally rare so I'm just assuming that this will probably be fixed before anyone notices.

In D21685, I've imposed stricter rules for which state transitions are allowed: for example, you can't issue a "pause" command to a build that is already pausing.

These make sense for humans clicking buttons in the web UI, but the API may be more useful if it is a bit more flexible and allows callers to issue no-op commands (e.g., pause an already-pausing build). So the distinction would then be:

  • Does the caller have permission to issue this command? (Web & API)
  • Is the build in a permissible state to receive this command? (Web & API)
  • Is the command useful to issue? (Human Web Only)

This ("Queued at") looks suspicious:

Screen Shot 2021-07-15 at 4.03.26 PM.png (44×302 px, 7 KB)