GitLab/Localization updates

Policy Migration status Workflows Project setup assumptions Registering an account on GitLab Hosting a project on GitLab Pipeline conversion Mirroring projects Configuring CI Publishing documentation Code review Making a merge request Squashing Managing security patches Deploying services to production Gerrit to GitLab Localization updates wikitech:GitLab GitLab implementation

This page aims to describe how translations via translatewiki.net would be setup with GitLab.

High level overview

Terminology:

• import: synchronize translations from code repositories to translatewiki.net
• export: synchronize translations from translatewiki.net to code repositories
• project: collection of code related code repositories. e.g. all MediaWiki extensions

Import steps

1. (Cron or manual) run a script that
   1. updates “read-only” code repositories to latest version
   2. compares repository and wiki state and produces a list of changes
2. (Manual) translatewiki.net translation admin approves the changes

Export steps

(Manual) run a script that, for each “project”:

1. updates all “write” repositories to the current state of “read-only” repositories
2. exports all translations from translatewiki.net
3. creates commits from changes (if any) and pushes them, e.g.
   • git commit && git review for repositories in Gerrit
   • git commit && git push origin translatewiki and create a PR or MR
   • git commit && git push master for other git repositories
   • similar stuff for subversion etc.
4. performs post-commit actions
   • for gerrit, run a script that loops over all L10n-bot open patches and does V+2

Per “forge” setup

• Create account for translatewiki.net and upload ssh key used for translation updates
• Add support for additional APIs on top of git/svn/etc. (PR/MR or Gerrit V+2)
• [Gerrit only] “Watchers” group that enables translation admins to overrule mediawiki-i18n-checker-docker over false positives

Per project/repository setup

• Push access to translatewiki.net account for the desired target branch
• [Gerrit only] Enable mediawiki-i18n-checker-docker on gate (security) (docs)

Gerrit vs. Gitlab wrt translation updates

Things that do not change:

• git is still git

Things that do change:

• ACLs are different
• commit and post-commit actions are different
• The way CI is setup is different
• Watchers group?

Open questions

• Is it possible to give ACL to L10n-bot so that it by default has access to all extensions and skins?
  • Yes, adding the bot account to the top level group (ie: extensions/) will give it rights to all new projects within the group (ie: extensions/my-new-extension).

• How do we (WMF) enforce mediawiki-i18n-checker-docker (or it’s GitLab equivalent) on all repositories, given CI is now under control of developers?
  • Using the ci_config_path we can point CI for each project to a high-level project that will wrap a project's .gitlab-ci.yaml
  • Wrapping will be achieved by including a local .gitlab-ci.yaml via the includes directive

What kind of process is best for committing:

1. Direct push to master branch
2. Push to another branch and create a MR automatically
3. Push to another branch and create a MR automatically and set auto-merge so that it gets merged if CI passes

Option 3 most closely resembles the current approach and minimizes the overhead for everyone. It is also an improvement over the Gerrit process, as it will no longer accidentally break tests. It will cause extra load on CI compared to Gerrit, and this will be very high peak (lots of commits in a short period of time). Can our instance handle it?

The auto-merge if pipeline succeeds option is documented, but not tested yet. As of last week, translatewiki.net has support for GitLab MRs, so that will not be an issue.

Asks from translatewiki.net

Extensions and skins should be organized as uniformly as possible. Any deviations will add extra overhead for translation admins at translatewiki.net. Namely:

• uniform hierarchy: e.g. mediawiki/extensions/{Ext1, Ext2}, not someuser/Ext1, someotheruser/Ext2
• uniform ACL: L10n-bot should have the required access by default
• uniform process: e.g. use master branch, MR+auto-merge

Example of currently streamlined configuration. Basically at minimum we just need to list the name of the extension in a file, with the rest of the configuration automatically created.