Harbormaster abort behaviour

I’ve recently setup CI using Harbormaster + Almanac + Drydock. Found it pretty straightforward to setup overall. I have two build plans – one for building diffs and one for building commits + doing continuous integration into our dev environment.

For the dev build plan, the first step is an Abort Older Builds command. Reading the documentation, it seems like this doesn’t behave the way I’d hoped it would. What I was hoping was that if a revision lands and there is a build in-progress for that branch, Harbormaster would nix that build and start a fresh one on the newer commit. It seems like that’s not how it works though. Instead, the documentation seems more Diff-centric (i.e. if this diff’s rev was already being built, kill it and start again).

Does that mean that Harbormaster doesn’t have the ability to auto-kill running builds of older revisions on the same branch out of the box?

Does that mean that Harbormaster doesn’t have the ability to auto-kill running builds of older revisions on the same branch out of the box?

This is correct. The underlying assumption is that building every commit on a branch is desirable, so you can figure out which commit actually broke a build when a failure arises.

In particular, if your commit velocity is greater than your build time (for example, master sees a new commit land roughly every 15 minutes, but the full set of builds takes roughly 90 minutes – which seem like plausible values), aborting builds of commits with descendants would potentially mean that no build ever completes, or only one build completes per workday (once activity subsides for more than 90 minutes in the evening).

If your build is really something like a deployment and you’re not worried about commit velocity exceeding build velocity, you can use “Wait for Previous Commits to Build” to guarantee in-order execution, but this will still build every commit.

1 Like

That’s super helpful. Thanks for clarifying. I’m curious what this “Wait for Previous Commits to Build” option is. It sounds like a Build Step. I see it in screenshots when I google for “Wait for Previous Commits to Build”, but I don’t have that option in the list of build steps when I edit the build plan.

The options I see are:

Drydock

  • Drydock: Run command
  • Lease Working Copy

Interacting with External Build Systems

  • Build with Buildkite
  • Build with CircleCI
  • Make HTTP Request

Flow Control

  • Abort Older Builds

Testing Utilities

  • Sleep
  • Throw exception

Oh, it looks like it’s gated behind phabricator.show-prototypes in Config. I don’t believe there are any actual issues with it, I think I just wasn’t sure if it was the approach I wanted to take toward tackling these build sequence problems. If you try it and it works for you, I’m happy to promote it out of prototype.

1 Like

I tried setting this in the web UI, but it’s disabled in the UI. Then instructions say to set this via the Phabricator config CLI, but our Phabricator setup is hosted with Phacility. Is there a way to use the command line Phabricator tools to interact with the Phacility-hosted service? If not, I’m not sure what lever I have that can flip this value.

Oh – just file a support ticket referencing this thread (admin.phacility.com > Manage Instance > Support) and I’ll follow up with you there.

(If you have access to Phacility Support, you’ll usually get a much higher-quality response much faster by using that channel than by using this forum.)

1 Like