Smoke test: run weekly and open an issue on failure

[afinetooth]

Problem

smoke-test.yml verifies the full end-user chain of the published @v2 across all four platforms. It's the right test — but it only runs when someone remembers to run it, and if it fails there's no reliable alarm.

The existing workflow_run trigger fires after releases of this repo. It never fires for changes underneath us:

• a new coverage-reporter release (the binary this action installs)
• a runner-image update (e.g. macos-latest moving from Sequoia to Tahoe)
• a Homebrew change (tap trust, formula/linkage rules, bottle availability)

Concrete example: coverage-reporter v0.6.18 shipped and nothing here fired. Verifying that end users would actually get it required remembering this workflow existed and dispatching it by hand. The header comment already says to run it manually after "a Homebrew major version, a runner-image update, or an action update" — and it still didn't happen until someone thought to ask.

Changes

1. Weekly schedule

schedule:
  - cron: "23 12 * * 1"  # Mondays 12:23 UTC

The job's existing guard already passes for schedule events (github.event_name is 'schedule', so the workflow_run conclusion check short-circuits). Cron is deliberately off the hour; GitHub delays scheduled jobs that pile up at :00.

2. Open an issue on failure

A report-failure job (needs: smoke, if: failure()) that opens an issue when any matrix job fails.

Email is a weak alarm for a scheduled job: GitHub sends scheduled-run failure notifications only to whoever last edited the cron expression — not to repo watchers — and if that person's notification settings are wrong, the failure is silent. Adding a schedule without an alarm would automate the check but not the alert, which is worse than not automating it: it looks watched when it isn't.

• Reuses the existing open issue via the smoke-test-failure label and comments on it, so a recurring weekly failure doesn't open 52 issues.
• Creates the label on first use — no manual setup.
• Scoped permissions: issues: write on the job, not the workflow.
• The issue body explains what a failure implies (end users are likely broken right now, even though nothing in this repo changed) and lists the usual causes.

Also updated the header comment so the docs match the triggers.

Why not repository_dispatch from coverage-reporter?

That was the alternative — fire immediately when a reporter release completes. Rejected because:

• secrets.GITHUB_TOKEN cannot dispatch cross-repo, so it needs a PAT with repo scope created, stored, and rotated — a new long-lived credential added to the release path we're trying to make more robust.
• It only fires on coverage-reporter releases, so it would not have caught runner-image or Homebrew drift — and two of the three breakages behind this work came from exactly that.
• "Immediate" buys little over "within 7 days" when the failure mode is drift going unnoticed for 11 months.

Verification

• YAML parses; both jobs present with the expected needs / if / permissions.
• The run: block was extracted and checked with bash -n to confirm the heredoc terminates correctly after YAML strips block indentation.

Note

GitHub auto-disables scheduled workflows after 60 days of repository inactivity. This repo is active enough that it shouldn't trigger, but the failure mode is "silently stops running" rather than "fails loudly" — worth knowing that absence of alerts isn't proof it ran.

🤖 Generated with Claude Code