Page MenuHomePhabricator

Cross-repository gating of changes pre-merge in Differential
Closed, DeclinedPublic


Gating is basically a way ensuring that master is always buildable even when cross repository dependencies are used. See upstream documentation about Zuul:

(Or, if you're more into having someone explain it to you with voice+slides, see: )

The current world
Right now we are working to integrate Differential and Gearman. (see T130949). This gives us Nodepool support for Differential change testing but it does not give us cross repository dependencies and gating.

Option 1: Differential support in Zuul???
There are rumors (@hashar can you link to any public documentation/plans from James E. Blair) that newer versions of Zuul will support non-Gerrit review systems as a 'trigger'. Without a timeline from upstream Zuul this is not something we can depend on.

Option 2: Gating support in Harbormaster???
Open question that @greg can't tell from a quick look at upstream documentation: does Harbormaster support cross-repo gating in a similar fashion as Zuul? Do you know, @mmodell?

Option 3: Push the 'gating' to before deploying???
Another option is not using gating and instead pushing back this functionality to A) watching to make sure Beta Cluster doesn't break and B) adding a pre-deploy review of a big cross-repo integration job that runs at some interval (hourly?).

Event Timeline

No harbormaster does not support 'gating.'

I have yet to be convinced that gating is something we actually want.

Removing the q4 project tag for two reasons:

  1. This is not needed for the near term future (iow: no repositories planned to migrate in the near term need it)
  2. It wasn't actually on our list of goals on the official list:

Still valid discussion and we are actually still working to address it, but it's just not an official task for this quarter.

After inspiration from many, I think there is a way to entirely remove gating in favor of test jobs after patch upload and jobs after deployment-prep that is not worse in outcome. However that requires substantial changes to mediawiki development, testing, integration, registration and deployment. AFAIK nobody yet has automation for all the additional manual work that would require (even for other software stacks). Some automated tracking that would ensure that the outcome is not worse in the sense of leaving stuff behind might be a good idea. That tracking could be tried on one of the stacks that we already use that are also lacking that tracking.

demon added a subscriber: demon.