Page MenuHomePhabricator

Gate-and-submit for release branch 1.39 and 1.41 fails for Babel and GrowthExperiments because it tries to install CommunityConfiguration (which does not have a 1_39 or 1.41 branch)
Closed, DeclinedPublic

Description

Failure for the release branches of Babel extension

01:22:39 INFO:zuul.Cloner.mediawiki/extensions/CommunityConfiguration:upstream repo is missing branch REL1_39
01:22:39 INFO:zuul.Cloner.mediawiki/extensions/CommunityConfiguration:Falling back to branch master
01:22:39 INFO:zuul.Cloner.mediawiki/extensions/CommunityConfiguration:Prepared mediawiki/extensions/CommunityConfiguration repo with branch master at commit 7ea27b1019508ac71b6dd4ac8075e3325310bb17
[...]
01:22:57 * A dependency error was encountered while installing the extension "CommunityConfiguration": CommunityConfiguration is not compatible with the current MediaWiki core (version 1.39.8), it requires: >= 1.43.0.

It is possible to exclude the dependency for the affetcted release branches?
Could the cloner ignore missing release branches instead of using master? (Maybe only if starts with REL*)
This also affects GrowthExperiments, but more extensions could follow as the extension is possible used more widly

See also T369279: Gate-and-submit-1_39 fails for CampaignEvents because it tries to install WikimediaCampaignEvents (which does not have a 1_39 branch)

Event Timeline

It's not ideal, but we've done things like this before:

if (
    params['ZUUL_PROJECT'] == 'mediawiki/extensions/Babel'
    and params['ZUUL_BRANCH'] == 'REL1_39'
):
    ext_deps.remove('CommunityConfiguration')

It will also fail for CommunityConfiguration on REL1_41.

Historically, I've just created a trivial retrospective branch of the new extension; the initial commit claims it requires MW 1.41+, but we could try branching it as 1.39 and fiddling that and see what happens?

I had reported the same issue in T369279. Would it make sense to remove the dependency by default, instead of falling back to master? Using master for a MW extension when testing a release branch probably isn't going to work anyway.