Summary Scap should learn to clean the old wmf branches from VisualEditor/VisualEditor

Problem

VisualEditor/VisualEditor has accumulated wmf branches since 2017 and has 447 of them:

$ git -C ~/projects/VisualEditor/VisualEditor ls-remote origin refs/heads/wmf*|wc -l
447

Due to a defect in the legacy Zuul (T374717) that makes its merge operations very slow because it iterates through each of the branches when updating the repository. Edit: looks like it takes 20 seconds on a zuul-merger, which is not the end of the world:

2026-09-17 12:05:17,447 DEBUG zuul.Repo: Updating repository /srv/zuul/git/VisualEditor/VisualEditor
2026-09-17 12:05:37,752 DEBUG zuul.Repo: Checking out 26216c0d7f24e83c7da6836fe1651bad193a7bff

Diagnosis

https://gerrit.wikimedia.org/g/VisualEditor/VisualEditor holds the code for VisualEditor which is supposedly a standalone project. It is deployed in production by being a submodule of https://gerrit.wikimedia.org/g/mediawiki/extensions/VisualEditor (which has wmf branch cleaned up as other repositories).

We have Scap automatically deleting the old branches when deploying. It once was broken which led to the accumulation of branches, that got resolved eventually via T303828 and for all deployed repositories, the wmf branches are properly cleaned up by scap nowadays but solely for repos being deployed with the exception of VisualEditor/VisualEditor (it is deployed indirectly by being a submodule). scap thus does not clean the wmf branches.

The branch comes from https://gitlab.wikimedia.org/repos/releng/release which defines a bundle wmf_core having all extensions and another bundle wmf_branch which extends it with VisualEditor/VisualEditor:

bundles:
...
    wmf_branch:
        - include: "wmf_core"
        - "VisualEditor/VisualEditor"

The relevant code in scap is in scap/clean.py cleanup_branch() which push a deletion over ssh for mediawiki/core and then do the same for each of the submodules. It does not process VisualEditor/VisualEditor, I guess we would need a special case to have it pass through extensions/VisualEditor/lib/ve.

Some thoughts:

• the submodule remote would be https rather than ssh, not sure whether it matters

• When archiving the REL* branches, I had to grant RelEng permissions to create tag and delete reference ( https://gerrit.wikimedia.org/r/c/VisualEditor/VisualEditor/+/1342706 ). The reason is VisualEditor/VisualEditor does not inherit from the mediawiki/ namespace and thus has its own set of permissions. The user used by scap to delete the branch might require an extra access list.