Feature request: Scheduler depending on multiple builds in same buildset

[YngveNPettersen]

There are likely a number of scenarios where input (including both build output results and properties) from two or more builds (different builders) in a buildset is needed by a secondary step in the build pipeline.

One scenario is building Mac x64 (intel) and Mac arm64 (M1, M2, etc) products (from different builders and workers), then combining them into a single "Universal DMG" installer. Build times of the first step is currently 3+ and 2+ hours, respectively

For the record:

• The Dependent Scheduler will not work. It depends on all builds completing (not just the subset of 2 or more related to the next step), and further it has no information about where the build output was stored, as it has AFAIK no properties from the upstream builder, including its sourcestamp. In fact, AFAICT Dependent will only work for single production branch projects, it won't work for our scenario, or most regular projects, given its limitations.

• Using a waitfor trigger in a secondary builder is also not going to work, in our case not the least because the next step depends on information from both the builds, which again depends on both schedulernames (multiple ones are in use, for different branches) and other build specific information, that have to be transferred to the next step. Such a procedure would also block a worker for the entire build period (which would be hours).

I have made an attempt at a multi trigger scheduler, but ran into problems that are AFAICT insurmountable without significant redesigns in buildbot, specifically that steps.Trigger.run does not complete the Trigger step until the sourcestamp and buildset has been created (used to link the step to the triggered build(s)).

While it could be worked around for the test, in my test system that caused a deadlock, as the next build task never got started (and while I am not sure, there may be problems with stopping the build because of the waiting deferrer). In our production system both builds would work in parallel, but the waiting would lock up the worker for an hour or more, depending on job scheduling, preventing other builds to start on the worker.

To work properly, the system would need the following properties:

• The scheduler is initialized with the upstream builders it depends on
• It will merge the properties from the upstream builders.
• It will wait for each dependent upstream builder in the buildset has sent a trigger signal to the scheduler and then create and start the new buildset, or, alternatively, the buildset completes without all triggers having been received by the scheduler, in which case the scheduler does not trigger, but records a failure
• The upstream Trigger steps needs to finish immediately, but leave a listener active to wait for the buildset or the failure notifications from the deferrers.

[policeakshithreddy]

"Would you kindly consider assigning this task to me? I'd greatly appreciate it."