Broadly, since I'd expect humans to sometimes run all the things that Harbormaster runs (to test, debug, profile, extend, etc., them), I'm assuming that this per-platform complexity should usually be pushed into projects so you can give humans one build process instead of separate per-platform build processes.

So both the ".sln" file and Harbormaster have essentially separate copies of the same platform-to-build-steps ruleset? Why isn't it "Protobuild.exe --generate" for Harbormaster, too?

If you were telling a human how to do the MonoGame builds, you'd pretty much point them at a wiki document with like 10 different sections, each of which had different steps and build commands on it and discussion about platform specifics? And they'd go through 10 similar-looking but ultimately separate build processes?

Can you walk me through why you have so many build plans? I understand that you might need one per, say, technology stack or team, but I don't understand why you'd ever have 100 unless you had a very large number of teams/projects, in which case I'd imagine it would be very rare to want to reconfigure any meaningful fraction of them at once.

Defining the v0 of this in greater detail -- largely just me thinking out loud:

We are also likely to build some sort of consensus framework (primarily to solve problems in T7639 / T7148) which provides generic support for "N of M users must approve this". This is a cleaner fit for having peers reset your MFA than putting a second weird review step on the merge pipeline, but maybe applicable at some point down the line.

I think we're ready to start laying in some of the groundwork for this. Per T9252, we now have hosted builds of commits and revisions in the upstream. This code still needs additional work and is missing a lot of generality, but the fundamentals seem to be in reasonable shape and I think we're on the path to stability.

Per T9252, we're now building all the repositories and all Community revisions, so the meat of this is working. There are still a lot of pieces that need refinement or generalization, though, or aren't even theoretically useful to installs other than this one for various reasons.

We are now building all of the repositories, and all revisions submitted by members of Community.

I'm not aware of any actual problem faced by installs today that the proposed feature is the best solution to -- nor can I imagine such a problem, even hypothetically -- so I don't plan to pursue it.

So, I can assume then that arc diff --skip-binaries doesn't actually skip binaries

We use these .gitignore rules in libphutil/ to avoid this problem with the .a and .o files generated by XHPAST:

If arc is trying to upload these files, that means you don't have VCS ignore rules configured for them, and suggests you're checking them in to the repository. If you're doing this, you'll have $4 of storage costs and a 4GB repository a year from now. In your second scenario, you'll have a 365GB repository. How are you planning to work with this repository? Why are you checking these files in?

1MB total per Diff update, on a small project. With 2-5 diffs per day, you can imagine that adds up fast over several months

I think D14239 fixes this, can you update and let me know if you're still seeing issues?

And as a followup, why are you checking .a and .o files into the repository? This is very unusual, and I would expect you to encounter severe scalability problems with the size of the repository on disk long before you encountered problems with the total data size of stored files.

probably earth-shatteringly vital before long

• We now accept any 2xx status as success.
• For (1) and (2) above, there is currently no support in the upstream, but builds can be parameterized after D14222. See T9352 for discussion and an example of how to write a custom Herald action which does this.

(I might not include this when I cut stable for this since the controller is a little bit of a mess, it's possible I missed something, and I don't expect it to be vetted much between 5PM Friday and 5AM Saturday.)

D14227 should fix our mishandling of these commits:

IIRC we report coverage per-test, for whatever little that's worth.

The way to do multiple builds per package is to use a remarkup custom field and separate them with newlines, correct?

Couple of issues I've seen so far:

Add a new Locale file here:

Allocate, but don't setActivateWhenAllocated(). You'll get a callback to activateResource() later. Check for an IP. If you have one, set it on the resource and call activateResource() to finish activation. If you don't have one yet, throw a yield and you'll get another call later. Repeat until you get an IP. Does that sound approximately reasonable?

Not exactly related, but we also have a fair number of multipart logs:

For some reason that I don't know offhand (maybe historic reasons, maybe just an error), this method returns the repository PHID of the active diff instead of the repository PHID of the revision itself.

After D14222, the updated P1860 should pass parameters properly. Here's a target getting a build parameter:

After D14219, you can adjust GC policies with the new bin/garbage.

I suppose we could let you disable statuses so new tasks can't be put into those states, while still retaining history for them.

I think that's basically the best we can hope for? Slightly cleaner is to use the batch editor before you remove the status to leave an audit trail and a comment like "We're getting rid of the blocked status so I'm moving this to Open, see Txxx for discussion." Or what were you thinking?

This is probably about an hour of work, although it may be a bit involved to distinguish between "the commit no longer exists in the repository" and other errors. If you want to prioritize this I can give you an hour-ish fix or a better estimate if it looks more complicated once I get into the code.

From what I understand, there is no way to update 'arc unit + arc lint' build plan.

T9494 discusses a GC TTL change I'd like to make before putting real GC here.

After D14190, you can do this with a vanilla "Command" build step that runs something like this:

+@avivey -- We talked about this briefly on IRC yesterday.

My plan is to allow parameterization at the build level; D13635 is an implementation of that but it has some other stuff mixed in and needs to be pulled apart a bit. I think this change is straightforward overall, though.

I think I'm not explicitly going to include anything to deal with this in v1 since the v1 resource types "probably won't" break for no reason, but I think we likely do need to have more formal tools for it soon. I roughly imagine:

The build step will probably let you configure that eventually, but I don't expect to change that any time in the near future.

We fail if the server returns an HTTP status other than 200, exactly. Since it's returning a "Location" header, it's probably returning a 3xx status alongside it. The behavior you describe is consistent with the HTTP request returning a non-200 status.