[jon8787]

What

Adds actions/check_jira_key — a composite action that fails a PR unless the squash commit that will land carries a UID2-<n> Jira key or a reasoned [no-jira - reason: <reason>] opt-out. This is the required-status-check enforcement path for IABTechLab (UID2-7426). Callers wire it as a pull_request job named check_jira_key.

(Originally drafted as a reusable workflow; converted to a composite action during review so the shipped logic lives in a unit-tested script rather than un-guarded inline bash.)

Why an Action instead of the native ruleset

UnifiedID2 / EUID (Enterprise) enforce this natively via a commit_message_pattern ruleset (UID2-7312). IABTechLab is a GitHub team plan, where commit-metadata ruleset rules are Enterprise-gated and never evaluated — proven live (and a ruleset required_status_checks rule does enforce on team plan, so this Action + a required check is viable).

What it checks — and the squash-config assumption

match.sh reconstructs the squash commit GitHub will land: subject = the single commit's first line (1-commit PR) or the PR title (multi-commit); body = all commit messages. It requires the key/opt-out there (checking the PR title alone is wrong — a single-commit PR lands the commit message, and the CI marker lands in the commit).

It assumes squash_merge_commit_title = COMMIT_OR_PR_TITLE + squash_merge_commit_message = COMMIT_MESSAGES (the config every gated repo uses) rather than reading it, because the workflow GITHUB_TOKEN cannot read squash_merge_commit_* (null without admin; administration is not a grantable workflow permissions: key — verified live). A runtime tripwire in action.yaml reads the settings anyway and fails loudly only if they are readable and differ from the assumption (null = unreadable = trust the enforcement) — so a UI settings-flip becomes an immediate red check at zero cost on the normal path.

Structure

• actions/check_jira_key/action.yaml — gathers inputs (live PR title + commits) + the tripwire, calls the matcher.
• actions/check_jira_key/match.sh — pure matcher (inputs via env, no I/O), holds the SSOT regex.
• actions/check_jira_key/tests/match.test.sh — 11 cases against the real match.sh.
• actions/check_jira_key/tests/regex_identity.test.sh — asserts the SSOT regex is byte-identical to the commit_pr_and_merge self-assertion (reads the real files → can't drift).
• .gitattributes — *.sh eol=lf (shebangs on Linux runners).

Both tests are auto-run by the existing test-scripts.yaml (no new CI wiring).

Review response (external review)

• F1 (CI merge 405s once required) — commit_pr_and_merge merges via an immediate PUT with no wait-for-checks. Documented as a required-flip prerequisite (add wait-for-checks, or bypass the release actor). Earlier "no CI change" claim corrected.
• F2 (squash settings unreadable → silent default) — the token genuinely can't read the fields (verified). Pivoted to assuming the uniform config + a runtime tripwire; uid2-android-sdk (was PR_TITLE/PR_BODY) is normalized to match, enforced via terraform.
• F3 — PR title fetched live (re-run safe).
• F4 — require-squash-merge must be active first (documented prerequisite).
• F5 — added \b to commit_pr_and_merge's assertion; a test now asserts the two copies stay byte-identical.
• F6 — failure guidance branches on single- vs multi-commit.
• F7 — squash subject uses the commit's first line.
• F8 — LC_ALL=C.UTF-8 for grep -P.
• Tests — the logic is now a unit-tested script (composite action), not a scratch mirror.

Rollout prerequisites (before flipping to a REQUIRED check)

1. Every gated repo is COMMIT_OR_PR_TITLE + COMMIT_MESSAGES (normalize uid2-android-sdk; enforce via terraform).
2. require-squash-merge is active.
3. commit_pr_and_merge waits for checks, or the release actor is bypassed on the required-check rule.

Validation

• test-scripts.yaml on Linux: match.test.sh 11/11 pass; regex_identity.test.sh byte-identical.
• E2E on uid2-attestation-api: no-key PR → check_jira_key fails; UID2-1234-in-commit PR → passes. Required-check context: check_jira_key.

[BehnamMozafari]

action.yaml fetches commits with pulls/${PR_NUMBER}/commits?per_page=100, which returns only the first 100 commits — but GitHub's squash body concatenates all of them. A key present only in commit #101 (and not in the PR title) would be missed, producing a false failure.

It fails closed (safe — no bypass), and it's a rare case, but it can block a legitimate large PR with no obvious cause. Consider paginating the commits call, or at least surfacing the 100-commit cap in the failure message so the reason is diagnosable.

[jon8787]

Fixed in 54e1080. The gather now paginates all pages (gh api --paginate … | jq -s '[.[][]]') instead of only the first 100, so a key in a commit past #100 (and not in the PR title) is no longer missed. GitHub still hard-caps PR commits at 250 — for that (pathological) case match.sh now surfaces the cap in the failure summary so a rare large-PR false-fail is diagnosable ("…if this PR has more, later commit messages were not evaluated — put the key in the PR title"). The pure matcher and its unit tests are unaffected.