ci: add per-PR EN-Revision hash check

[lacatoire]

Adds a GitHub Actions workflow that runs on every pull request and verifies that the EN-Revision header in modified XML files points to the latest doc-en commit for that file.

How it works

• Triggered on pull_request events targeting master
• Collects the list of .xml files changed in the PR
• For each file that also exists in doc-en, reads the declared EN-Revision hash
• Compares it against git log -1 on the matching doc-en file
• Emits a ::error annotation and fails if the hash is missing or outdated

This ensures that translation updates always reference the exact upstream commit they are based on, making future sync work easier to track.

Prior art

This check is already in use in doc-fr, doc-ru, and doc-es. There is also an ongoing initiative in doc-base to provide reusable workflows that all doc-* repos can share.

[alfsb]

@lacatoire , the filtering of XML files and inputting of while loop occurs at the done line? I do not know bash enough, and wondered if the while loop runs one time with empty data.

[lacatoire]

The .xml filtering isn't done at done, it's git's pathspec -- '*.xml' that limits the output. The done line only feeds the loop via the process substitution < <(...).

And no, it doesn't run once on empty data: while read reads line by line, so when git diff outputs nothing, read hits EOF immediately and the body runs zero times (fail stays 0). Proof:

$ n=0; while IFS= read -r f; do n=$((n+1)); done < <(printf ''); echo "$n"
0

(That's also why < <(...) is used instead of a pipe: it keeps the loop in the current shell, so fail survives.)

[alfsb]

Cool. I do not know that bash is that "functional style" capable.

[alfsb]

Note to myself: check if this CI does not conflict with revcheck / consecutive skip-revcheck.

[leonardolara]

Uma boa verificação na minha opinião. Às vezes esqueço de atualizar o rev-tag ou não envio uma tradução que não é da última revisão.

[alfsb]

Pode desconsiderar o "Note to myself" acima, ao avaliar esse PR. Após uma triste noite, eu re-descobri que o CI do GH desconsidera alterações no main/master. Ele faz um merge no master, sim, mas em um master no passado, não do presente. Como não é algo que não faz sentido para mim, isso não fica na minha cabeça.

Só para alertar, caso não já não soubesse desse detalhe. Isso não faz tanta diferença na tradução aqui, que quase nunca tem PRs concorrentes, mas é... triste, em repositórios com muitas alterações e/ou muitos PRs.

Mas fica também a pergunta, se há interesse que o CI aqui faça testes com um merge no master atual em vez do passado, que daí eu posso tentar, dentro das minhas limitadas capacidades, alterar o CI nesse sentido.