Skip to content

ci: add multi-platform release workflow for ruvector-mcp#408

Open
namesreallyblank wants to merge 1 commit intoruvnet:mainfrom
namesreallyblank:ci/release-ruvector-mcp-workflow
Open

ci: add multi-platform release workflow for ruvector-mcp#408
namesreallyblank wants to merge 1 commit intoruvnet:mainfrom
namesreallyblank:ci/release-ruvector-mcp-workflow

Conversation

@namesreallyblank
Copy link
Copy Markdown

Summary

Adds .github/workflows/release-ruvector-mcp.yml, a release workflow for the ruvector-mcp binary modeled directly on the existing release-rvf-cli.yml. Triggered by ruvector-mcp-v* tags (or manual workflow_dispatch); builds five targets in parallel and uploads the binaries plus SHA256 sidecars to a GitHub Release.

This is the second half of the PR #406 split per @ruvnet's review. The companion PR is #407 (workspace tokio io-std fix) — that fix needs to land before any ruvector-mcp-v* tag will actually build green, since the binary currently fails to compile on a clean workspace.

Addresses PR #406 review feedback

# Reviewer comment Resolution
1 Stale "template for contributors" header Replaced with a single-line description
2 Tag pattern too broad (v*) Scoped to ruvector-mcp-v*, mirroring the rvf-v* convention used by release-rvf-cli.yml
3 Single-target Windows-only build Now a 5-target matrix (Linux x64/arm64, macOS x64/arm64, Windows MSVC) matching release-rvf-cli.yml exactly
4 SHA256 only printed to logs, not uploaded Per-binary *.sha256 sidecar uploaded with each artifact; aggregated checksums-sha256.txt also attached to the Release
5 dtolnay/rust-toolchain@stable is a moving tag Kept unpinned for parity with release-rvf-cli.yml (informational item per review — not a regression)

The file is also renamed from release-windows.yml to release-ruvector-mcp.yml to match the neighbor naming pattern.

Structure

The workflow follows release-rvf-cli.yml step-for-step (same actions/checkout@v4, dtolnay/rust-toolchain@stable, Swatinem/rust-cache@v2, actions/upload-artifact@v4, actions/download-artifact@v4, softprops/action-gh-release@v2). The build job specifies cargo build -p ruvector-cli --bin ruvector-mcp --release --target … since ruvector-mcp is a binary inside the ruvector-cli crate.

One intentional deviation from rvf-cli's pattern

release-rvf-cli.yml ships only an aggregated checksums-sha256.txt for the whole release. Per @ruvnet's review point #4, this workflow additionally attaches a per-binary <name>.sha256 sidecar with each platform asset (so a user grabbing one binary doesn't need to download the manifest separately). The aggregated manifest is also published, so consumers can use either flow.

Test plan

Out of scope

  • Pinning dtolnay/rust-toolchain@stable to a specific SHA — would prefer to do this across both release-rvf-cli.yml and release-ruvector-mcp.yml in a single hardening pass rather than one-sided here

Mirrors release-rvf-cli.yml's 5-target build matrix (Linux x64/arm64,
macOS x64/arm64, Windows MSVC). Triggered by ruvector-mcp-v* tags or
manual workflow_dispatch. Each target uploads the binary plus a
SHA256 sidecar to the GitHub Release; an aggregated checksums-sha256.txt
manifest is also published.

Addresses PR ruvnet#406 review feedback from @ruvnet:
- One-line header (no stale "template for contributors" preamble)
- Scoped tag pattern (ruvector-mcp-v*, not bare v*) so tags do not collide
  with rvf-v* or hypothetical future component tags
- 5-target platform matrix (no longer Windows-only); structure and action
  versions match release-rvf-cli.yml for consistency
- Per-binary SHA256 sidecar attached for verification (rvf-cli ships only
  an aggregated checksums-sha256.txt; ruvector-mcp publishes both)
- File renamed to release-ruvector-mcp.yml to match neighbor naming

Note on dtolnay/rust-toolchain@stable: kept unpinned to match the
existing release-rvf-cli.yml convention. Pinning to a specific SHA can
be done across both workflows in a separate hardening pass.

This workflow will only produce working binaries once the workspace
tokio io-std fix from a companion PR lands (the ruvector-mcp binary
otherwise fails to build).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant