ci: auto-sync server.json versions before MCP Registry publish

[vaaraio]

Problem

The MCP Registry publishes whatever version is committed in server.json and server-vaara-server.json. Nothing bumps those files on release, so a forgotten manual manifest bump publishes a stale version and the post-publish assertion fails. This is the cause of the failed Release runs for v1.17.0 / v1.18.0 and the 3 straight Republish failures. PyPI and npm were fine, so the failures were invisible externally while the MCP manifest fell behind.

Fix

Add a step in both release.yml and republish.yml, right before publishing, that rewrites .version and .packages[].version in both manifests to the released tag (release) or the requested input (republish). The manifests are now always in sync at publish time regardless of what is committed. jq is pre-installed on ubuntu-latest runners.

No effect on the current registry state (already at 1.19.0, isLatest, active for both listings). This prevents the next release from recurring the failure.

Summary by CodeRabbit

• Bug Fixes
  • Updated release and republish workflows to automatically align published manifest versions with the target release version.
  • Prevents version mismatches that could block publishing or cause post-publish checks to fail.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: a5d9ba1e-6b0d-4712-8d1d-49aee8a8f1bd

📥 Commits

Reviewing files that changed from the base of the PR and between 9f29b32 and aba7315.

📒 Files selected for processing (2)

• .github/workflows/release.yml
• .github/workflows/republish.yml

---

📝 Walkthrough

Walkthrough

Two CI workflow files (release.yml and republish.yml) each gain a new step that rewrites the .version and .packages[].version fields in server.json and server-vaara-server.json to match the current release tag or requested version before executing the existing MCP registry publish logic.

Manifest Version Sync in CI Workflows

Layer / File(s)	Summary
Version sync steps in release and republish workflows .github/workflows/release.yml, .github/workflows/republish.yml	Both workflows insert a step before publishing that uses jq to rewrite .version and .packages[].version in both manifest files; release.yml sources the version from github.ref_name and republish.yml from EXPECTED_VERSION, both stripping any leading v.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Possibly related PRs

• vaaraio/vaara#176: Directly modifies server-vaara-server.json version fields that these workflows now automate syncing at release time.

Poem

🐇 Hop, hop, the version's set,
No stale manifest to regret!
jq rewrites with a temp-file swap,
Release and republish close the gap.
The registry gets the tag just right —
This bunny ships clean every night! ✨

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly captures the core change: auto-syncing manifest versions before MCP Registry publish.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/republish-version-sync

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}