Topic on Talk:GitLab consultation

Current translation updates in Gerrit have one benefit and one drawback. The benefit is that they are merged automatically. The drawback is that they skip most of the tests and such cause merge blockers.

Currently Gerrit requires explicit +2 to have a change merged (if it passes tests). In GitLab this is rather the other way around: you can require tests to pass first, then you can merge (if you have sufficient access). To prevent merging unwanted code to the master branch, I assume we will be enabling branch protections to disallow direct push to the branch. This means that we would not be able to push translation updates directly anymore.

I think GitLab allows to set exceptions per-repo level, but I do not think that is sustainable: extra work to configure each repository, and we could end up with different repos doing it in different ways, making configuration on translatewiki.net side more complicated.

Is there way to set such exceptions globally, or perhaps per group level?

The other option would be that translation updates are send as merge requests, and merged immediately if tests pass. This avoids the drawback of the current system of skipping tests. I also think it's possible to give the translation updater account global permissions to do that across repos, and I saw GitLab even provides a merge_request.merge_when_pipeline_succeeds option to easily do that. I think this would be the best workflow for translation updates.

I agree that running localisation updates through the regular merge process would be a good idea; we don't with the current architecture to avoid too much extra load on the CI servers, at the cost of the occasional test-violation pain, as you say. Switching to just "normal" C+2/gate is something we could do now, and is the easiest thing for the new GitLab world, I imagine.