All six workflows here are workflow_call-only, so none of them trigger on this
repo's own pushes or pull requests. There is no test suite, no run script and
no lefthook config. A YAML syntax error or a bad ${{ }} expression is caught
by the first consumer that calls it, after merge to main — which is what every
consumer pins.
translation-status.yml raises the exposure: it carries the most embedded shell
of the six, with a PATCH/POST branch, PIPESTATUS handling and an
outcome-conditional step.
actionlint covers this cheaply and runs shellcheck over run: blocks. It
was run by hand against translation-status.yml before merge; nothing makes
that repeatable. Run it on pull_request over .github/workflows/ and
examples/.
This will not catch semantic mistakes — the if: steps.anchors.outcome == 'failure' condition that skipped when the gate failed was valid YAML and a
valid expression. It catches the syntax class, which is currently caught by
nobody.
All six workflows here are
workflow_call-only, so none of them trigger on thisrepo's own pushes or pull requests. There is no test suite, no
runscript andno lefthook config. A YAML syntax error or a bad
${{ }}expression is caughtby the first consumer that calls it, after merge to
main— which is what everyconsumer pins.
translation-status.ymlraises the exposure: it carries the most embedded shellof the six, with a PATCH/POST branch,
PIPESTATUShandling and anoutcome-conditional step.
actionlintcovers this cheaply and runsshellcheckoverrun:blocks. Itwas run by hand against
translation-status.ymlbefore merge; nothing makesthat repeatable. Run it on
pull_requestover.github/workflows/andexamples/.This will not catch semantic mistakes — the
if: steps.anchors.outcome == 'failure'condition that skipped when the gate failed was valid YAML and avalid expression. It catches the syntax class, which is currently caught by
nobody.