Push changes through merge requests in Damned Lies

Infrastructure
1

Hi all GNOME hackers,

For those who are using Damned Lies to translate their software − which means all GNOME Core and many Circle and others apps, we have some change to announce.

Last year, this old issue has come to the fore again: Support pushing translations to GitLab as merge requests rather than pushing directly to git. You have probably heard about the XZ-utils backboor situation and has a consequence, I understood that some of you want to disallow Damned Lies, as anyone, to directly push your translations to protected branches

What I would like by posting this message here is to collect your needs, aside of what’s already written on the issue tracker.

The process I propose you is the following:

  • If you wish to use merge requests instead of direct pushes, you will have to set whether you allow Damned Lies to push to your repository or to push translations through merge requests.
    • We will propose you to update your CI/CD so that we will not trigger pipelines on Damned Lies MR.
    • Or, we will propose you to auto-merge the request after checking there is only a PO file that has been updated.
  • When a translation workflow ends and the translation is validated:
    • The committer pushes the button to commit the translation.
    • It opens a merge request against the project and the merge request is linked to the workflow on Damned Lies.
    • When the merge request is actually merged, Damned Lies updates the feed and informs the translation workflow participants.

I think we will have to open merge requests for every single language, but I think we should propose a way for maintainers to automatically accepts incoming requests from Damned Lies after ensuring (automatically) they are only changed PO file and these files are correct.

3 Likes
2

I thought the main point of projects wanting MR’s for translations, is that they do get checked by the CI workflow.

As for gimp-help, for which I am maintainer, translations regularly break our CI, most of the time due to unfamiliarity of XML tag handling by translators. If we decide to use MR’s for Damned Lies, the main reason would be that the MR’s get validated by our CI.

That would mean that your MR’s could get blocked due to failing validation, in which case you would probably need to provide feedback from the MR to your translation interface.

3

Wouldn’t the compromise here to only run a reduced pipeline that does the things that are relevant for validating the correctness of the translation changes?

4

Validating the correctness usually implies building the whole project.

Merge requests adding/updating a translation can probably avoid running the test suite, but I don’t see any particular reason why translations should be exempt from checks. Translators are not owed any particular benefit compared to any other contributions, and there’s no reason to have a translation getting merged immediately after being made.

5

Thanks for this Guillaume! The plan sounds good to me. As with the other commenters above, when I enable this for GLib I would:

  • Run the CI for the translation MRs, so they are tested
  • But then try and set it up so those MRs are auto-merged as soon as they pass CI

I’m guessing your aim with avoiding CI and/or getting changes auto-merged is to try and avoid translation MRs sitting around unmerged for a long time due to inactive/unavailable maintainers?