ci: lint workflow invariants actionlint misses (concurrency, SHA pinning, payload deny-list)

[dgageot]

actionlint is already in CI but it does not validate event-payload
schemas — that's how PR #2645 slipped through (github.event.issue.type
is not a real field for the issues: labeled trigger). This PR adds
a small bash check, run after actionlint in the existing lint job,
that encodes three project-specific invariants:

1. PR-triggered workflows declare a concurrency: block — prevents
   piled-up runs on rapid pushes;
2. Third-party uses: references are pinned by 40-char SHA —
   defence-in-depth for supply-chain attacks;
3. Workflows do not reference fields on a post-mortem deny-list
   (currently github.event.issue.type, from PR docs(github): update issue templates and triage workflow #2645). Easy to
   extend in scripts/workflow-lint.sh whenever a new bad pattern
   shows up in review.

What it caught immediately

pr-review-trigger.yml had no concurrency: block — fixed in this
PR by keying the group on the PR number so overlapping runs cancel
per-PR.

Cost

• 1 step in ci.yml (runs in the existing lint job, no new job).
• 1 portable bash script (~110 lines, self-tested in a fixture
  .github/workflows/ tree).
• 0 net additions to the existing CI runtime — actionlint and the
  new script together complete in well under a second.

[docker-agent]

Assessment: 🟡 NEEDS ATTENTION

Three confirmed issues in the newly-added scripts/workflow-lint.sh — all in logic that defines the invariants the script is supposed to enforce. The CI integration (ci.yml) and the concurrency: addition to pr-review-trigger.yml look correct.

[docker-agent]

[MEDIUM] docker/ namespace exemption is documented but not implemented

The comment at lines 65–68 explicitly states that the docker/ namespace is exempt from the SHA-pinning check, but the case statement only skips '', './'*, and '../'* — there is no 'docker/'* arm:

case "$ref" in
  '' | './'* | '../'*)
    continue
    ;;
esac

Any docker/ action referenced without a 40-char SHA (e.g. docker/setup-buildx-action@v3) would be incorrectly flagged despite the documented exemption — or conversely, if the intent is for docker/ actions to also require SHA pinning, the comment is misleading and should be updated. Either way, the code and the comment disagree.

Suggested fix — if docker/ should truly be exempt, add it to the case arm:

case "$ref" in
  '' | './'* | '../'* | 'docker/'*)
    continue
    ;;
esac

Or remove the exemption from the comment if docker/ actions are also required to be SHA-pinned (which is arguably the better security posture).

[docker-agent]

[MEDIUM] Check 3 uses regex grep (-E) but the comment promises literal matching

The comment directly above says "The check is a literal grep", but the implementation uses grep -nE (extended regex) — the dots in github.event.issue.type are regex metacharacters that match any character rather than a literal .:

matches=$(grep -nE -- "$ref" "$WORKFLOWS_DIR"/*.yml ...)

While githubXeventYissueZtype is vanishingly unlikely in a YAML file today, this is a latent bug: any future deny-list entry containing [, (, *, +, or ? will either over-match or cause grep to error. The code also doesn't escape the string before passing it as a regex.

Suggested fix — use -F (fixed-string) to match the comment's guarantee:

matches=$(grep -nF -- "$ref" "$WORKFLOWS_DIR"/*.yml "$WORKFLOWS_DIR"/*.yaml 2>/dev/null || true)

[docker-agent]

[MEDIUM] Concurrency check misses compact on: [pull_request] array syntax

The pattern ^\s*pull_request: requires a trailing colon, so it only matches the expanded YAML map form. A workflow that declares triggers using the compact sequence syntax is silently skipped:

# These forms are missed by the current check:
on: [pull_request, push]
on: [pull_request]

Both syntaxes are valid and commonly used across public GitHub Actions workflows. A new workflow added using this form would pass the lint check with no concurrency: block, defeating the invariant.

Suggested fix — match both forms:

if grep -qE '^\s*pull_request:|on:\s*\[([^]]*,\s*)?pull_request' "$f"; then

Or more simply, match pull_request anywhere in the on: block and accept the low false-positive rate the comment already acknowledges:

if grep -qE '^\s*pull_request[: \[]' "$f"; then