At least some installs have been using Drydock in production for a while. This could be made easier -- and this task still has the best guide for it -- but I think nothing actionable here remains.

I'll call this out in the changelog, but behavior here is changing slightly (see T13258 and T11415):

The revision editor and diff editor should no longer be racing to edit the diff. The two revision editors may be racing now, but that race is significantly easier to resolve if it crops up.

This should work again now. The behavior probably needs refinement -- I don't remember exactly where we left it and I think there was some disagreement about who should or shouldn't receive build failure notifications before D10911 accidentally disabled this, but I think T9892 and other Harbormaster tasks discuss most of that.

File a bug report please.

It didn't work for me.

Here's what I'm thinking here:

• Add lint/unit/coverage "summary" field to each Build.
• Recalculate whenever new lint/unit objects show up (Possibly offline via daemon).
• arc-side lint/unit already generates a Build, so this one will hold the --nolint/--nounit information (+ excuse?)
• Anywhere we currently show that information, load the summary information and aggregate that, instead of aggregating all lints/units directly.

I don't think there's anything actionable remaining here that isn't covered elsewhere.

This should maybe also somehow interact with Artifact Files.

Aha! That makes sense, thanks for digging into it!

tl;dr: looks good!

Awesome, thanks!

I have a 500mb repo somewhere, and it would reproduce very easily to me, so I'll test this.

After D15427, this should be pretty clear for "Land Revision".

After D15424, arc fails when failing to push the staging area.

I've marked D15424 as fixing this, although I don't have a detailed understanding of exactly what goes on in the git protocol and which heuristics it is using. In particular, I haven't been able to trick it into doing too much work locally (maybe it also looks at parents?).

Drydock and Almanac are now available in the cluster. Here's a rough guide to configuring them -- I'll turn this into something formal once things work a little more smoothly.

Yeah, that claim assumes someone will arc diff some published commit sooner or later (i.e., run arc diff while on master with no local changes). While this wouldn't happen on a normal workflow or on purpose, I suspect it happens more-often-than-never.

From what I see, this doesn't actually normalize over time, if the staging repo is used only for staging: none of the /diff/ refs will ever be a parent of master from the real repo, because of the rebase during arc-land (I've written this at some point in Manual Staging Area Caveat).

Quick update here ahead of deployment tomorrow:

Yes, this should eliminate the need to sync/cron/do anything.

Would this eliminate most of the benefit from cron based "sync refs from the main repo" glue?

• Provide some way to treat "too much output" as a categorical build failure, similar to how you might treat "excessive runtime" as a build failure.

@epriestley : sorry, I should have searched more thoughtfully.

Current plan here is:

@tycho.tatitscheff See T8656 or Planning.

Is support of ansi color possible in this harbormaster iteration ? I mean not only parse the ansi code but also generate a markup based on the color.
As far as I remenber it wasn't the case.

This is detailed in T10463, but the API changes seem to have deployed with only a few minor rough patches, so we're currently on track to deploy everything else next Saturday (March 5).

I believe our Harbormaster log table is several GBs in size and by several GB I'm talking 20-80GB range depending on the last time I hard deleted the records.

Pretty sure I can scope this into the current iteration under T10457 and provide some corresponding purge tools, just in case any installs hypothetically insert gigabytes of data into build logs.

My broad philosophical stance here is that engineers should be disciplined and professional about not killing enemy builds, but I think the complexity cost to put some more guard rails on the thing isn't overbearing and these additional policies are generally pretty reasonable and make sense, and have some redeeming value in preventing mistakes with tools like "Restart All Builds".