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

That shows up in the UI like this, and you could list a bunch of build names in it:

Then you drop this into phabricator/src/extensions/:

...and write a rule to run the action unconditionally:

This almost works. It starts the builds correctly (here, the three "HTTP request to Google" builds were started because of this chain of configuration/magic):

However, there's currently no way to parameterize at the build level, so these three builds are identical instead of differing by a parameter. Fixing that will require some upstream adjustments.

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.

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

So your target can use ${build/build-name-from-owners} to pass this to something like Jenkins:

...and it should pop out on the other side:

• 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?

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

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

The herald rule should be "Always" instead of something to do with packages because CustomDifferentialRunPackageBuildsHeraldAction has sufficient logic of it's own?

Yeah. You could add additional conditions, but the action only runs build plans per configuration in affected packages, so there's no way to run "too many" plans. But you could add rules like "Day of week is not tuesday" if you have "No Tests Tuesdays" in your company or whatever.

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

A list feels ideal, but that's not an existing custom field type. It's mildly unsightly to have the full remarkup bar there but that isn't a big deal at all.

I've promoted this to our primary installation and arranged all the sticky gluey ends so they connect together and did a full end to end test. It worked, and everything seems good in theory, yeah!

My next step is to start adding more builds and confirming everything holds up in practice.

At HEAD, you can now edit this field via the owners.edit Conduit API method.

We ran into a case where archived packages were trigger builds, which didn't feel right and was causing problkems. I'm not sure what the default behavior loadAffectedPackages should be or what would be most consistent with how archiving is handled elsewhere.

diff --git a/config/phabricator/extensions/CustomDifferentialRunPackageBuildsHeraldAction.php b/config/phabricator/extensions/CustomDifferentialRunPackageBuildsHeraldAction.php
index 5bf3593..366b06d 100644
--- a/config/phabricator/extensions/CustomDifferentialRunPackageBuildsHeraldAction.php
+++ b/config/phabricator/extensions/CustomDifferentialRunPackageBuildsHeraldAction.php
@@ -34,7 +34,7 @@ final class CustomDifferentialRunPackageBuildsHeraldAction
     $buildplan_phid = "PHID-HMCP-ue7dbgw57fwxzmeadqfx";
 
     $adapter = $this->getAdapter();
-    $packages = $adapter->loadAffectedPackages();
+    $packages = mfilter($adapter->loadAffectedPackages(), 'isArchived', true);
 
     $package_phids = mpull($packages, 'getPHID');
     $this->logEffect(self::DO_BUILD, $package_phids);