Skip to content

feat(release): tell tenjin when the MCP Registry pin goes stale - #181

Open
A1igator wants to merge 1 commit into
mainfrom
A1igator/release-pin-notify
Open

feat(release): tell tenjin when the MCP Registry pin goes stale#181
A1igator wants to merge 1 commit into
mainfrom
A1igator/release-pin-notify

Conversation

@A1igator

Copy link
Copy Markdown
Contributor

Scope

A successful changeset publish now files one issue on BackTrackCo/tenjin asking for the MCP Registry pin bump, so a release stops staling that listing in silence. Option 1 (notify) from #98; the auto-PR shape and auto-publishing stay out.

  • scripts/notify-registry-pin.sh reads the published version from changesets/action's publishedPackages, dedupes on an exact open-issue title match, and files an issue naming server.json, package.json, and lib/mcp/metadata.ts (where MCP_SERVER_INFO lives since tenjin#493), plus the rule that the registry publish stays manual and follows a promoted deploy.
  • .github/workflows/release.yml gates the new step on steps.publish.outputs.published == 'true', so a dispatch that shipped nothing announces nothing.
  • scripts/pack-smoke.sh asserts the packed mcpName is blog.tenjin/tenjin, the npm precondition Wire the MCP Registry packages pin into the release pipeline #98 asks for: dropping it breaks tenjin's next registry publish, not anything here.

Risk: the step runs after npm already has the package, so a failure there cannot un-publish. Until the owner action below is done it will fail the release run (loudly, on purpose: an unnoticed miss is the bug being fixed).

Owner action required

Create repo secret RELEASE_CROSSREPO_TOKEN: a fine-grained PAT scoped to BackTrackCo/tenjin with Issues: read and write.

#98 assumed the release-bot token already in that job would do. It will not: the x402r-release-bot installation holds contents: write, pull_requests: write, metadata: read and no Issues permission, and it is installed on this repo (and x402r-sdk), not on tenjin. Widening the App would need both a new permission grant and a new repo in its installation, so the token is parameterized on a named secret instead. RELEASING.md carries this as one-time owner setup step 4.

Testing

  • src/notify-registry-pin.test.ts: 7 cases driving the real script with gh stubbed. Files once per version; files nothing on a no-op publish or when the publish carried no tenjin-cli; skips a same-title open issue; still files when only the previous version's issue is open (the loose --search alone would swallow it); fails and writes nothing without a token; links the release run.
  • pnpm lint, pnpm typecheck, pnpm format:check: clean.
  • pnpm test: 2147 passed, 10 skipped.
  • bash scripts/pack-smoke.sh: PASS, including the new mcpName assertion.
  • Verified live (read-only) that gh's gojq resolves env.TITLE, which the dedupe query depends on.

Closes #98

A successful `changeset publish` now files one issue on BackTrackCo/tenjin
naming the newly published tenjin-cli version and the files that must move
with the pin. The registry rejects version ranges, so the pin is exact and
lives in the other repo, where nothing notices it going stale until the next
registry publish preflight weeks later.

Closes #98

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@A1igator A1igator added the priority: high High priority label Aug 18, 2026

@greptile-apps greptile-apps Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your trial has ended. Reactivate Greptile to resume code reviews.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

priority: high High priority

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Wire the MCP Registry packages pin into the release pipeline

1 participant