See T9530.

@avivey: I'm somewhat interested in this if you have any tips for getting it working locally I would like to try it out and see if I can contribute anything towards a finished extension.

I've made some progress in the direction of this task in D16981 and D17020, but I've since then more-or-less lost the external pressure to implement this. I might get around to completing this eventually, but I might not.
The code in those diffs is mostly usable, but it does require some amount of local extensions to be implemented. If anyone is interested in trying it out (Or even taking over the changes), I can instruct you on how to do it locally and what's missing.

In T9530#177353, @hach-que wrote:

So I was thinking about software components recently and one of the issues I've had with both Jenkins and Harbormaster is that builds of one repository aren't aware of the builds from another repository. This is a common scenario in the software I build:

• DiffusionCommitQuery has had the "good" version for a while.
• We're nuking Releeph at some point.

@hach-que what you describe is being used by OpenStack (a cloud management system) for their CI. They wrote an adhoc software named Zuul and the feature you describe match the description at http://docs.openstack.org/infra/zuul/gating.html It is using Gerrit (a code review tool by Google for Android) as a source. So you are not alone :-]

One thing that happened locally wrt "Product Lines" and 40 apps:

• RelMan wants to think about the 40 apps going out at the same time as a single thing, even if they have slightly different code changes.

For instance, they want to cut them all at the same time, and deploy them all to the staging environment/prod in one go, etc.
ATM, that means that we have a single Release with lots of repos in it, but that might one day grow into a "Meta-Release"/"Release Bag"/"Train", which is basically a collection of releases that are managed together.

So I was thinking about software components recently and one of the issues I've had with both Jenkins and Harbormaster is that builds of one repository aren't aware of the builds from another repository. This is a common scenario in the software I build:

FWIW, at the WMF we make releases that involve hundreds of repositories: one for mediawiki, plus one for each mediawiki extension that we host. I don't think it is an ideal situation, and it causes me all kinds of grief, but it's the current state of affairs. So there is at least one potential use case for a release that encompasses a snapshot of multiple repos.

The future of these pipelines in the upstream is server-side, not client-side. See T9530.