Change Details

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. See also PHI1390, which is adjacent. See also PHI1966, which wants access to the `build` command.

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).

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).