ci: file a tracking issue when a scheduled smoke run fails

[ian-flores]

Closes #632

A scheduled run has no PR author to notice it, and the Workbench nightly was red for five consecutive days without surfacing anywhere. connect-integration.yml already posts to Slack on failure, but its webhook secret is Connect-specific and the convention was never extended to the other suites.

Adds a notify-on-scheduled-failure composite action and wires it into the status jobs of the Workbench, Connect, Package Manager and mock-IdP workflows. It files one tracking issue per workflow and comments on it for repeat failures, so weeks of nightly breakage produce one issue rather than a pile. It uses the built-in GITHUB_TOKEN with a narrowly scoped issues: write, so no new secret is required — which is what ruled out simply copying the Connect Slack job, since Workbench and Package Manager would each need their own webhook.

De-duplication matches the issue title exactly against the open issues, compared client-side rather than handed to --search: the search index tokenises its input, is only eventually consistent, and reads a colon as a qualifier separator, none of which a de-duplication key tolerates. --state open is what makes closing the issue the way to ask for a fresh one on the next failure.

Every call site is gated on failure() && github.event_name == 'schedule', so pull-request failures stay quiet.

Manual step

The nightly-failure label has to be created in the repository. The action already degrades to filing the issue without a label and emits a workflow warning, so nothing breaks before that happens.

Testing

All 22 workflow and action files parse. The body generation was run locally against both the new-issue and repeat-failure paths and produces no leading indentation — four leading spaces would have rendered the entire issue body as a code block, which is what the first draft did. The de-duplication filter was exercised against both a matching and a non-matching issue list. CI's two enforced zizmor audits, unpinned-uses and artipacked, both report 0.

Note for review order

This touches the same four smoke workflows as #633. The edits are in different places — a step inside the status job here, versus timeout-minutes on job headers there — so whichever merges second should rebase cleanly, but it is not conflict-free by construction.

[Copilot]

🟡 Changes recommended

The new notification action’s de-duplication logic is brittle (hard dependency on jq + a low issue-list limit), which can undermine the goal of reliably surfacing scheduled failures.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR ensures scheduled (nightly) smoke workflow failures are surfaced automatically by filing a de-duplicated tracking issue (or commenting on an existing one), addressing the “silent nightly failures” problem described in #632.

Changes:

• Added a composite action that creates or updates a “Nightly failure: …” GitHub issue for scheduled-run failures.
• Wired the action into the status jobs of the Workbench, Connect, Package Manager, and mock-IdP workflows (gated to failure() on schedule runs).
• Tightened job permissions and added checkout in status jobs so the local composite action can run with GITHUB_TOKEN.

File summaries

File	Description
.github/workflows/workbench-smoke.yml	Adds permissions + checkout to status job and calls the new notification action on scheduled failures.
.github/workflows/connect-smoke.yml	Adds permissions + checkout to status job and calls the new notification action on scheduled failures.
.github/workflows/packagemanager-smoke.yml	Adds permissions + checkout to status job and calls the new notification action on scheduled failures.
.github/workflows/mock-idp-e2e.yml	Adds permissions + checkout to status job and calls the new notification action on scheduled failures.
.github/actions/notify-on-scheduled-failure/action.yml	New composite action that de-duplicates by exact title and files/comments on a tracking issue for scheduled failures.

Review details

• Files reviewed: 5/5 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.