ci: add per-PR EN-Revision hash check#413
Conversation
|
Thanks for this, and for the work across the other translations. I've measured it against doc-ja's master and I'm going to decline it.
On ja That gap is a defect doc-base already documents.
Timing matters too. alfsb has just validated the consecutive- Separately, the check evaluates against doc-en HEAD at run time, so a green PR turns red when doc-en touches one of its files, with nothing the contributor can do about it. Closing. Happy to revisit once php/doc-base#181 or its successor lands and the check can consult revcheck's hash list rather than |
|
"The hash that mark a file as ok" seems simple at first, but is really complicated. One possible solution would be revcheck lib exporting the per file "ok list" of hashes, so this test would only be possible after running revcheck itself. But please, do not try to make changes here, as this is.. a very delicate place of doc-base. You may perhaps create a companion of I sincerely thought no one understands these code parts, or the reasons as they need to be so complicated, to cover many different styles of file tracking between translation teams. Thanks, your reasoning above made my day a lot happier. |
Adds a GitHub Actions workflow that runs on every pull request and verifies that the
EN-Revisionheader in modified XML files points to the latestdoc-encommit for that file.How it works
pull_requestevents targetingmaster.xmlfiles changed in the PRdoc-en, reads the declaredEN-Revisionhashgit log -1on the matchingdoc-enfile::errorannotation and fails if the hash is missing or outdatedThis 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, anddoc-es. There is also an ongoing initiative indoc-baseto provide reusable workflows that alldoc-*repos can share.