Page MenuHomePhabricator

Script closing/archiving of migrated repositories on Gerrit
Closed, ResolvedPublic

Description

When moving repos to GitLab, we need a standard process for how to handle their old location on Gerrit. I need to do things in the phabricator/ namespace, and decided to script something for future use. Paired on this with @jeena yesterday. What we have so far is:

https://gitlab.wikimedia.org/repos/releng/gerrit-migrate

Assumptions were that we should do something like here:

https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/tools/scap/+/refs/heads/master

Which means deleting all files on the primary branch, replacing the README with one that points to the new location, and updating the description to include "[MOVED TO GITLAB]".

After discussion with @thcipriani, it seems like a better idea might be:

  • Point HEAD to a new branch, something like MOVED_TO_GITLAB, which is empty and contains only a README that describes the new location
  • Delete old primary branch

The rationale here is that:

  • There's code in puppet (and maybe elsewhere) which automatically fetches various things.
    • It's a safe bet this happens in places that the person migrating a given repository won't know about.
  • A fetch that silently deletes all files could lead to a serious outage.
  • A fetch that fails with an error is more likely to alert than to cause public-facing breakage.
  • This matters less, but it's kind of weird to have divergent history between the Gerrit repo's version of e.g. master or wmf/stable and the new GitLab repo.

Event Timeline

brennen changed the task status from Open to In Progress.Feb 22 2023, 10:10 PM

Kind of piggyback riding: Somehow updating the custom Source Repo field in Phabricator project descriptions would also be very neat (but a separate request).

Kind of piggyback riding: Somehow updating the custom Source Repo field in Phabricator project descriptions would also be very neat (but a separate request).

Good idea. Might not be too bad to roll into something like this.

I wonder if we could make migrated Gerrit repos read-only and show that fact in the UI outside of the repo itself.

In my imagination the perfect migration and least error prone would be if nothing at all changes when I clone the repo ... but whenever I have the idea to change something I obviously notice I can't push to it anymore and then when I go to the UI I see a large banner on the repo detail page that informs me that it moved to Gitlab and how I should change my git source.

I am not entirely convinced that files in repos that have moved elsewhere have to be deleted and replaced with a README at all.

Might even find it slighly nicer if they stay around just like "static bugzilla" tickets stay around forever as historic archive (and once all repos have been moved the question will come up anyways when a decision has to be made if Gerrit is shut down or stays around readonly. Losing all gerrit comments and reviews would be bad too).

This task is similar to what is done when archiving Gerrit project as part of the Projects-Cleanup project. We have defined few steps that have to happen ( https://phabricator.wikimedia.org/maniphest/task/edit/form/33/ ), I guess some from there can be reused for the purpose of moving a repository from Gerrit to Gitlab.

+ @Kizule who has been nicely helping on the front of archiving repositories and dealing with all the related config change.

In my imagination the perfect migration and least error prone would be if nothing at all changes when I clone the repo ... but whenever I have the idea to change something I obviously notice I can't push to it anymore and then when I go to the UI I see a large banner on the repo detail page that informs me that it moved to Gitlab and how I should change my git source.

Something like this does seem ideal in some ways. It's kind of weird to have 2 copies of the project around with divergent history, and pulling a repo where you then have to reset to a different upstream's history could be kind of weird.

(It would be cool if we could get Gerrit to print a banner or something over SSH on a pull, although I wouldn't have any idea how to do that.)

The API docs say:

Read Only:

The project is read only and all modifying operations on it are disabled. E.g. this means that pushing to this project fails for all users even if they have push permissions assigned on it.

Setting a project to this state is an easy way to temporary close a project, as you can keep all write access rights in place and they will become active again as soon as the project state is set back to Active.

This state also makes sense if a project was moved to another location. In this case all new development should happen in the new project and you want to prevent that somebody accidentally works on the old project, while keeping the old project around for old references.

New proposal for overall process:

  1. Update in-repo README mentioning new GitLab path as canonical.
  2. Push to main on a new GitLab project
  3. Update the Gerrit description to say "MOVED TO GITLAB"
  4. Set project state to READ_ONLY (also doable via API / ssh)
  5. Remove any relevant tests in integration/config (zuul/layout.yaml).
  6. Convert any relevant tests for GitLab (see also T327332: Make a tool to convert .pipeline/config.yaml to .gitlab-ci.yaml)
  7. Update any external docs

The list is obviously going to be longer for something like MediaWiki extensions, but what other obvious stuff am I missing for projects in general? The list @hashar linked above is useful, but it's not quite the same problem since this is for moving rather than closing a given thing.

🚲🏠