publish.yml: notify on failure

[stonematt]

Problem

publish.yml fails silently. Nothing surfaces a failed release.

Concrete instance: run 33986727640 (2026-09-05) failed publishing v2.1.0. The NPM_TOKEN secret had expired on 2026-08-18, so npm publish returned:

npm error code E404
npm error 404 Not Found - PUT https://registry.npmjs.org/mcp-obsidian-cli
npm error 404  'mcp-obsidian-cli@2.1.0' is not in this registry.

The tag v2.1.0 was already pushed by that point, so the repo looked released while npm, the MCP Registry, and GitHub Releases all stayed on 2.0.4. It sat that way for three days and was only caught by accident while working on an unrelated PR.

The failure mode compounds: the npm step dies first, which skips the MCP Registry publish and the GitHub Release creation. One expired credential silently drops all three.

Acceptance criteria

• publish.yml has a job or step guarded by if: failure() that fires when any publish step fails.
• The notification names the failing step, the version being published, and links the run URL.
• The notification is durable and pull-based, not a channel that scrolls away. An auto-opened GitHub issue is the default choice; a labeled issue is easy to spot and closes when fixed.
• Repeated failures do not open duplicate issues for the same version.
• Verified by a deliberate failure on a branch (e.g. a bad token in a test run), not just by reading the YAML.

Notes

Token expiry will recur — the replacement token has its own expiration date. This issue is about surfacing the class of failure, not preventing this one cause. See the Trusted Publishing issue for removing the token entirely.

[stonematt]

This was generated by AI during triage.

Agent Brief

Category: enhancement
Summary: A failed release publish opens a durable, de-duplicated GitHub issue, driven by a checked-in script rather than inline workflow YAML

Current behavior:
The publish workflow is a single linear job. Every step after the version-determination step is gated on the same skip output, and there is no if: failure() anywhere in .github/workflows/. When npm publish fails, the job stops and the remaining steps — MCP Registry publish and GitHub Release creation — never run. Nothing outside the Actions run page records that the release did not happen.

Because the git tag is pushed before the publish steps, the repository looks released while npm, the MCP Registry, and GitHub Releases all stay on the previous version. Run 33986727640 (2026-09-05, v2.1.0) failed this way on an expired NPM_TOKEN and went unnoticed for three days.

Desired behavior:

Failure detection is a separate workflow, not a step inside the publish workflow. It triggers on the completion of the publish workflow and acts when the conclusion is failure. This decoupling is the point: a guard living inside the publish job shares that job's fate, while a completion-triggered watchdog still runs if the publish job dies, times out, or is cancelled.

The watchdog's only job is to invoke a checked-in Node script. All decision logic — which step failed, what version was being published, whether an issue already exists — lives in that script, not in YAML. The script follows the repo's existing conventions: ESM, no new dependencies, dependency-injected externals so it is unit-testable, alongside the other entries in scripts/.

Given a failed run id, the script must:

• Resolve the failing step name by reading the run's jobs from the Actions API and selecting the first step whose conclusion is a failure.
• Resolve the version being published deterministically from the run itself — read package.json at the run's head commit, or parse the tag when the run was tag-triggered. Do not read the working tree, which may have moved on.
• Compose a stable title that includes the version, so the same failed version always produces the same title.
• Search open issues carrying the failure label for that title before writing anything. If one exists, add a comment with the new run URL instead of opening a second issue. If none exists, open one.
• Emit a body naming the failing step, the version, and the run URL.

The script must support a dry-run mode that resolves everything and prints the issue it would create or comment on, without writing. This is what makes the behavior verifiable locally against a real past failure — including run 33986727640 — with no need to break a release to test it.

Key interfaces:

• A script in scripts/ exporting a testable entry function that takes the run identifier and an injected API caller, mirroring how createObsidianCli accepts an injected execFile. The CLI wrapper around it stays thin.
• A dedicated label for these issues, created if absent, so the issues are filterable and visually distinct in the tracker.
• The watchdog workflow needs issues: write and actions: read; it reads another workflow's job data, which the default contents: read does not cover.

Acceptance criteria:

• A workflow separate from the publish workflow triggers on the publish workflow's completion and acts only when the conclusion is a failure.
• The notification names the failing step, the version being published, and links the run URL.
• The notification is a GitHub issue carrying a dedicated label, so it persists until closed.
• A second failure for the same version comments on the existing open issue rather than opening a duplicate; a failure for a different version opens its own issue.
• The decision logic lives in a script under scripts/, not in workflow YAML. The workflow step is effectively a single invocation.
• The script has unit tests under test/ using node:test with an injected API caller, covering: failing-step extraction, version resolution for both a tag-triggered and a branch-triggered run, the create path, and the dedupe-to-comment path.
• npm test passes.
• Dry-run mode against run 33986727640 resolves the failing step as the npm publish step and the version as 2.1.0, and prints the issue it would open. Record that output in the PR.
• The PR notes that a completion-triggered workflow only arms once it reaches master, so the first live confirmation happens on the next release.

Out of scope:

• Changing when the git tag is pushed relative to the publish steps. The tag-before-publish ordering is the reason a failure looks like a success, but reordering it is a separate change with its own release-ritual implications.
• Removing NPM_TOKEN or migrating to Trusted Publishing — that is Migrate npm publish to Trusted Publishing (OIDC), drop NPM_TOKEN #102. This issue surfaces the class of failure and stays useful after Migrate npm publish to Trusted Publishing (OIDC), drop NPM_TOKEN #102 lands.
• Notifying on anything other than the publish workflow. The test workflow already fails visibly on PRs.
• Auto-retrying or auto-republishing a failed release.
• Any channel other than a GitHub issue — no email, chat, or webhook fan-out.