CI: branch collision handling for translation templates updates

[Dasux]

This PR resolves the issuue #7115 ... related to the update-i18n job in the Periodic update workflow.

Previously, the workflow used a static branch name:

periodic/update-i18n

This meant that every time the workflow ran, it reused the same branch to create or update a Pull Request. As a result, only one translation update PR could exist at a time. If the workflow was triggered again (either by schedule or manually) while a previous PR was still open, the same branch would be reused and the existing PR would be updated or overwritten.

What was changed

The branch name used by the create-pull-request action has been updated to include a unique identifier:

periodic/update-i18n-${{ github.run_id }}

so this ensures that

• each workflow run creates it's own branch
• multiple translation PRs can coexist at the same time... without interfering with one another
• no existing PR is unintentionally overwritten

Verification

The workflow was manually triggered manually on a fork repo, and the branches were different each time. Each run created a distinct branch and corresponding Pull Request, confirming that branch names no longer collide.

Note:

Assistance from AI was used for understanding the issue and hinting towards a solution

[echoix]

Can you review the diff, and only changes the lines needed? You removed lots of comments, changed comments where not needed, in short, it’s hiding the real useful changes.

Add yourself in the loop, like we wrote in the contribution guidelines/ai policy, and come ping me back when it will be worth it :)

Your solution with the run_id is probably better than using the ref/base_ref (that was previously mentionnend), as it it less prone to injection, so a bit better on security.

[Dasux]

i reverted docker.yml

[Dasux]

1. merged the latest main into the branch and resolved the conflicts...
2. restored the removed comments and cleaned up the workflow so the diff only reflects the intended changes.

[Dasux]

Also, as a rule of thumb moving forward, how should PRs be titled?
I’ve noticed one workflow occasionally fails when the PR title doesn’t match the repository’s conventions.

[echoix]

Take a look again at what I have to review, it doesn't seem humanly reviewed-reread

[echoix]

Also, as a rule of thumb moving forward, how should PRs be titled?

I’ve noticed one workflow occasionally fails when the PR title doesn’t match the repository’s conventions.

Look at the other (merged) PRs, and the output of the failed workflow. It checks for some known categories, and shows the allowed ones.

Read again https://github.com/OSGeo/grass/blob/main/CONTRIBUTING.md and also the part where it links to https://github.com/OSGeo/grass/blob/main/doc/development/github_guide.md#pr-title

[echoix]

Bad rebase

[echoix]

Either you are rebasing with a main that is behind, like your fork’s main branch, you are not using upstream/main (assuming the remote for this upstream repo is called upstream in your local env).

It’s easier when there’s no force pushes yet, but to get out of it, you need to check one of both and do another force-push (which I say again, is not pleasant when reviewing has started)

[Dasux]

very bad rebase..... i know...

ill go back to the previous commit hash---

[Dasux]

hopefully now the diff shows only the intended changes ....

[echoix]

hopefully now the diff shows only the intended changes ....

Thanks, now reviewing was almost limited to two chunks, so way easier!

[Dasux]

I removed the concurrency part...

Also..

hopefully now the diff shows only the intended changes ....

Thanks, now reviewing was almost limited to two chunks, so way easier!

thank you for being patient and guiding me along the way
really appreciate it...

[echoix]

You just need to resolve the review comments, some might be hidden somewhere because of the force-pushes