Add script for syncing changes back to l10n-central

[eemeli]

We’re averaging about 100 localization commits a day, and it’s far too easy to imagine finding some issue with the new setup after a few days’ or even weeks’ operation. So I think it might make sense to initially sync commits from git to hg, so that we can switch back whenever.

Filing initially as a draft as the authentication for hg.mozilla.org is not yet included.

[eemeli]

Based on a suggestion from @moz-hwine, simplify this to just sync to the git repo's locale branches. A developer will then need to have a local repo set up like this from which they can pull the changes from GitHub and push them to the hg.mozilla.org repos:

git config push.default upstream
git fetch origin
while read lc; do
  git checkout $lc;
  git merge --ff-only origin/$lc;
  git push;
done < firefox-locales

[eemeli]

The action relies on a tag last-sync being available, and that not being present is by design. This action should not be run until the cthulhu-merge has been committed to the main branch, which name is hard-coded into the action.

[bcolsson]

If we add a new locale in the future, would we then also need to create a last-sync for that?

[eemeli]

Depends when that happens. I would not expect to keep this running for more than a month or two post-migration.

Also, the last-sync is a single tag for all locales.

[bcolsson]

Ok, so the likelihood would be low, but we might need to be careful if we do add one. In particular I'm not familiar enough with filter-repo enough to know if that step would fail if it can't find the subdirectory in the base tag. There's no error handling in the workflow.

[eemeli]

There's no error handling because the script is intended to fail ASAP if it goes off the happy path, so that any issues can be solved manually.

If a new locale is added post-migration but while we're still keeping the option to roll back to hg, the only requirement from this script is to also add a corresponding single-locale branch to which its changes may be written. For an actual rollback, we'd need to also create a new l10n-central repo for it.

[eemeli]

I'll run this script occasionally (maybe once a week or so?), so that if we do need to apply a rollback, we'll have the data ready for that. It will need some oversight at least initially, so best not to make it timed or automatic.