[askalf]

What changes, and why

scorecard-action reports a failed publish to scorecard.dev as a warning, and the run stays green. On 2026-11-09 the scheduled Scorecard run of askalf/pitlane had its publish answered 500 three times. scorecard.dev then served "not found" for the repository for about fifteen hours, the README badge read "invalid repo path", and no run was red. One clean publish cleared it.

This adds the check for that, as a fifth shared action:

• scripts/scorecard-publish/check.mjs, run by actions/scorecard-publish-check (a JavaScript action on the runner's Node, like actions/fleet-status) on workflow_run of a repository's Scorecard workflow.
• A run is checked when it succeeded on the default branch of a public repository. Any other run is left alone and the step passes.
• For a checked run it reads https://api.scorecard.dev/projects/github.com/<owner>/<name>, the address the badge reads, up to four times, 15 s apart.
• Published means the result served carries a time of day and that time is no earlier than a minute before the run's start; the minute allows for clock skew. The results this action publishes are dated to the second: the API served 2026-11-09T10:25:29Z and 2026-11-10T01:38:45Z for askalf/pitlane's publishes of those days, and the tests use those values. A date with no time of day is OpenSSF's own weekly scan, which no run of ours wrote, so it is never taken for a run's publish, whatever its day.
• An unpublished schedule, push or branch_protection_rule run: the Scorecard workflow is dispatched on the default branch once, with a warning.
• An unpublished workflow_dispatch run: the step fails. A dispatch is never answered with another, so one failed publish costs at most one extra run, and a publish that fails twice is a red run.
• It cannot be a step of the Scorecard job: scorecard.dev accepts results only from a job whose steps it recognises.
• The run's facts reach the script as inputs of the action, each defaulting to the workflow_run event's own field (github.event.workflow_run.id and so on), so a caller passes none and the script reads no file. A workflow_run that arrives with no run id fails the step. The workflow file must be a plain file name under .github/workflows; the default branch is used as GitHub names it and is sent only as a JSON string in the dispatch body.

pin.mjs lists the action in ACTIONS and redline-pin-bump.yml watches its two directories, so its pins move with the other actions'. The README has the caller workflow and a section on the check; scripts/scorecard-publish/README.md has the rules.

Two things this relies on and does not prove:

• that the runner fills an action input's default from github.event.*, as it does from github.token. If it does not, the first run fails on the missing run id, which is why that is an error and not a skip; a caller can then pass the inputs itself.
• that the run dispatched with the job token fires workflow_run for the check in turn. If it does not, the retry still happens and only the second check, the one that turns a twice-failed publish red, is missing.

How it is tested: node test-all.mjs passes (all 12; the new one is scripts/scorecard-publish/check.test.mjs, also added to the test job). It covers which runs are checked, a default branch with a + or a letter outside ASCII, the dating rule with the dates the API served and with date-only values, and main against a stubbed scorecard.dev and GitHub: a published run, a result that arrives on a later read, the 2026-11-09 case (404 on every read, one dispatch of scorecard.yml on main with the job token), an older result, only the weekly scan's result, no answer, an unpublished dispatch failing with nothing sent, a dry run, a refused dispatch, a missing run id, a default branch with a + and quotes sent as a JSON string, and a workflow path that is not a plain file name. The action's entry is run for real for the paths that make no request, and a test holds each input's default to its event field.

Not tested: the action on a runner against the real scorecard.dev. No repository calls it yet.

Callers: no caller runs anything new until it adds the workflow. pin.mjs and the pin bump's watch list change, so the next pin bump moves every caller's existing pins to this commit. The callers' own scorecard-publish.yml files come after this merges, pinned at the merged commit.

[sprayberry-redline]

Verdict: approve. The check bounds its polling, dispatches one retry for an unpublished run, and fails an unpublished dispatch without starting another. The tests cover freshness, skipped runs, request failures, dispatch handling and input wiring; the new action is also included in pin updates and the test job.