We had a very slow week and haven't made much progress here. There is a new list view and some new, more reasonable UI. We landed our first production change with this mechanism.

What is the timeline?

One followup in T9573 but I don't think anything exploded, otherwise.

Progress here:

General progress update here: this now works, technically. Almost every part of it -- particularly, the UI -- is still total garbage for now, but if you ship a revision against rGITTEST up to this server you'll get a "Land Revision" button on it which has worked twice in the past and might work again. I would recommend extending the list of pasta varieties found in the pasta file if you want to try this (the button should appear and function without requiring the revision to be accepted for now, and everyone has write access to the repo anyway).

Yup! Much improved, thanks.

@aj can you confirm this has been resolved?

@justinkao can you confirm this has been resolved?

At HEAD:

Blueprint selection (which got more details in T9519) is now in a rough-but-functional state so I expect the rest of this to move forward shortly.

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.

mmm meat

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.

Yeah, at least as written. You could tweak the logic or I can swap it for something else if that's easier.

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

• The way to do multiple builds per package is to use a remarkup custom field and separate them with newlines, correct?
• The herald rule should be "Always" instead of something to do with packages because CustomDifferentialRunPackageBuildsHeraldAction has sufficient logic of it's own?

Couple of issues I've seen so far:

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?

@epriestley I just tried to start reimplementing some of my patches on top of HEAD and I've run into a problem:

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

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.

In T9123#138576, @epriestley wrote:

We're kinda-sort doing builds for commits now:

We're kinda-sort doing builds for commits now:

We technically have builds now:

Quick progress update here: Owners packages now have configurable custom fields, so you can add one like this:

Resources still do not have expiration behaviors.

There's some relevant information on the progress on the Drydock side of this here: T9252#138215

These things are now complete: