Page MenuHomePhabricator

[Task] make core wmf branches only use submodule branches that run with it in CI
Closed, DeclinedPublic

Description

Make core wmf branches only use submodule branches that run with it in CI. E.g. if an extension with a branch named wmf/1.26wmf22 is run in CI it is only tested with other wmf22 branches, but if that branch is included as a submodule in core wmf24 then it was never tested against that branch. (Thank you @Krinkle for pointing out yesterday that we should improve that.)

From https://git.wikimedia.org/blob/mediawiki%2Ftools%2Frelease/269841a760da05bde32f782dcf7fe9fd28d56980/make-wmf-branch%2Fconfig.json
There is a list:

"special_extensions": {
       "CentralNotice": "wmf_deploy",
       "Wikidata": "wmf/1.26wmf22",
       "SemanticMediaWiki": "1.8.x",
       "SemanticResultFormats": "1.8.x",
       "Validator": "0.5.x"
}

Semantic* are dealt with in T75940.

No idea about CentralNotice and Validator. Anyone?

Wikidata branches not every week, it might be fine to copy the old branch into the new one. Downside of that would be needing to sometimes backport to two branches which would double the work of a backport, but I'd prefer that over not properly testing with CI. mediawiki/tools/release seems to have an option for that (set the key from above to true instead of a string). I'd suggest to do that.

Event Timeline

JanZerebecki raised the priority of this task from to High.
JanZerebecki updated the task description. (Show Details)
JanZerebecki added subscribers: JanZerebecki, Krinkle.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 25 2015, 2:11 PM

Should we do what I suggested in the description for Wikidata?

JanZerebecki set Security to None.Sep 25 2015, 2:12 PM
JanZerebecki moved this task from incoming to needs discussion or investigation on the Wikidata board.

Change 241658 had a related patch set uploaded (by JanZerebecki):
Wikidata extension: copy latest wmf branch

https://gerrit.wikimedia.org/r/241658

Change 241658 merged by jenkins-bot:
Wikidata extension: copy latest wmf branch

https://gerrit.wikimedia.org/r/241658

I don't quite understand the problem, and I really don't understand how changing the make-wmf-branch config is going to resolve it? This sounds like a bug in the way CI testing is configured.

The CI matches extension branches with core branches by name. If it works this resolves it for wikidata by copying the branch which means that each wmf wikidata branch is always run together with the core version it is deployed with. Before it would run wikidata wmf22 with core wmf22 but never run wikidata wmf22 with core wmf23, but it is deployed with both.

Making the CI read the configuration file from make-wmf-branch and also the meadiawiki-config file for which deployment branches are still active to make it run the right extension branches with the right set of core branches might work. We are talking about 3 extensions which do not follow the convention of aligned branch names with core. I think in this case convention over configuration is the better approach. That means make the deployment and CI for all extensions work exactly the same way.

CI should just check out all the submodules by following the submodule sha1 references in the core branch, then it wouldn't matter how the branches are named, ci would do the right thing by simply letting git do the right thing.

If CI isn't doing that now then it's a bug in the CI setup.

Jonas renamed this task from make core wmf branches only use submodule branches that run with it in CI to [Task] make core wmf branches only use submodule branches that run with it in CI.Sep 30 2015, 10:11 AM

CI should just check out all the submodules by following the submodule sha1 references in the core branch, then it wouldn't matter how the branches are named, ci would do the right thing by simply letting git do the right thing.

That wouldn't fully cover what the CI does today, e.g. what would you do after uploading a patch to the repo mediawiki/extensions/Wikidata.git to a wmf branch? (There is an unfinished patch related to this: https://gerrit.wikimedia.org/r/#/c/161225/ ) Also there are other places besides CI where the same assumptions are baked in. Anyway, I would welcome improvements to the CI.

If CI isn't doing that now then it's a bug in the CI setup.

It could also mean that how 3 extensions out of many are branched for wmf deployment violations the branching rules. Do you have an argument for why it should be more configurable than always matching branch names?

The feature we tried by the patch didn't work as said in: https://phabricator.wikimedia.org/rMREL731742221ac2#inline-67

Later the following was discussed:

<jzerebecki>	 twentyafterfour, hoo: no when the branch doesn't already exists it should copy from the previous one instead of master
<twentyafterfour>	 jzerebecki: that would cause a proliferation of branches (which we already have everywhere else but I wish we didn't)
<jzerebecki>	 twentyafterfour: i just want to make wikidata more like every other extension, having a deploy branch for every core deploy branch is a step. so if you change everything else to not proliferate... we could do that instead.
<twentyafterfour>	 jzerebecki: I'm not too concerned either way but shouldn't we have the consensus of the wikidata team to make such a change? If you have already came to that decision then I'm fine with it, but make-wmf-branch is very inflexible and hard to fix so I need to know which way it should behave in order to fix the script
<twentyafterfour>	 that is to say, I'd rather not fix it twice ;)
<jzerebecki>	 twentyafterfour: that is the consens. I just rechecked with key people to make sure.
hashar added a comment.EditedOct 26 2015, 5:23 PM

The idea of mediawiki-extensions-* jobs was to test ahead of time what the result of wmf branch will be. As early as when a patch is proposed to master branches.

I proposed it back in Nov 2014 https://www.mediawiki.org/wiki/Requests_for_comment/Extensions_continuous_integration and it is half completed :-/

The idea was to have a reference of extensions/skins to be deployed on Wikimedia production. I though the list in make-wmf-branch would be of good use since we update it before creating the branches. From there we have four scenario:

  1. Adding a new extension to make-wmf-branch
  2. Patch to extensions master branches
  3. Patch to mediawiki wmf branches
  4. Patch to extensions wmf branches

Adding a new extension to make-wmf-branch

Propose a patch that which adds it to make-wmf-branch
We trigger a job that has all the extensions listed in make-wmf-branch using their master branches
Run the tests.

If tests pass, that mean the extension can be added to the next wmf branch since it will be made of the master branches.

That scenario needs a reference of extensions/skins to clone outside of the wmf branches.

Patch to extensions master branches

Clone of the extensions listed in make-wmf-branch at master.
Run the tests.
A failure will prevent the tests from falling in the next wmf branch

That scenario needs a reference of extensions/skins to clone outside of the wmf branches.

Patch to mediawiki wmf branches

There we can simply use the submodules of mediawiki/core

  • git submodule update --init --recursive
  • include all extensions and skins
  • run the tests

If that pass the patch to mediawiki/core wmf branch get merged.

Patch to extensions wmf branches

That is where it becomes scary.

We would clone mediawiki/core wmf branch and process submodules

Then read the /.gitmodules and have zuul-cloner apply the proper references crafted by gate-and-submit. One trouble is that it might fall back a tip of a branch that has been updated in the extension but has not yet updated the submodule.

Example:

  • extension A updates its wmf branch mediawiki/core wmf branch is NOT updated
  • extension B updates its wmf branch
  • a patch proposes to update B in mediawiki/core wmf branch

When doing the submodule update, extension A does no't include the patch above. But zuul-cloner will checkout the branch from the repo.


Potentially we could have mediawiki/core wmf branches to be automatically updated whenever a patch is merged in an extension wmf branch.

Or we could get rid of the submodules in mediawiki wmf branches and just use the tip of the wmf branches from each extensions.

But I thought that mediawiki core is updated when a patch is merged to an extension.

With "Patch to extensions wmf branches" is B the one under test? Then A will AFAIK correctly be at what the submodule says. Only B will possibly be ahead of its submodule (more ahead than the patch under test), but that is what we want. Which wmf core branch(es) will you use here? The same extension wmf branch may be used in more than one core wmf branch. Maybe if the same tests were ran again when updating the submodule in core wmf branches we would only need to test with one core branch.

With "Patch to mediawiki wmf branches" are you proposing to stop automatically updating core wmf branches?

Potentially we could have mediawiki/core wmf branches to be automatically updated whenever a patch is merged in an extension wmf branch.

As @mmodell points out, that is what is currently happening for some wmf core branches (the one with the same name as the extension wmf branch and the latest). Neither for manual nor automatic submodule updates is there currently a test run for updating the submodule. AFAIK the current automatic way can not be used together with a test run.

Krinkle removed a subscriber: Krinkle.Nov 2 2015, 11:44 PM
JanZerebecki moved this task from in progress to monitoring on the Wikidata board.Nov 3 2015, 10:59 AM
JanZerebecki added a subscriber: Krinkle.

I got another case.

mediawiki-extensions job get broken because zuul-cloner tries to find a matching branch for wikidata and ends up falling back to master branch which is not quite what we want.

So for wmf branches we want to process mediawiki/core submodules, then have zuul cloner to attempt to checkout the reference and NOT fallback.

@hashar any idea what the state of this one is?

hashar closed this task as Declined.Aug 23 2019, 2:30 PM

That is no more needed, ton of things have changed since the task got filled. Notably:

  • The Wikidata extension is no more
  • The wmf branches are automatically updated by Gerrit
  • All extensions have the wmf branch cut from master except CentralNotice
Restricted Application removed a subscriber: Liuxinyu970226. · View Herald TranscriptAug 23 2019, 2:30 PM