Add: CI pipeline for mcpproxy

[matheusfrancisco]

No description provided.

[qodo-code-review]

PR Summary by Qodo

Add GitHub Actions CI with automated semver releases and binary publishing

✨ Enhancement ⚙️ Configuration changes 📝 Documentation 🕐 20-40 Minutes

AI Description

• Add PR label enforcement to require a single release bump label before merge.
• Automate semver tag + GitHub release creation on merges to main.
• Build and attach cross-platform binary archives and checksums to each release.

Diagram

graph TD
  PR["Pull Request"] --> L["PR Label Check"] --> M["Merge to main"] --> AR["Auto Release"] --> GR[("GitHub Release + Tag")] --> BR["Binary Release"] --> AS["Archives + checksums"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Adopt GoReleaser for build+release

• ➕ Standardized cross-compilation, checksums, SBOM/signing options
• ➕ Less bespoke bash/gh scripting to maintain
• ➖ Introduces new tool/config to learn and pin
• ➖ Still needs a versioning strategy (labels vs conventional commits)

2. Use Release Please (or similar) for versioning/changelog

• ➕ Automated version bumps and release notes based on commit/PR metadata
• ➕ Reduces custom semver computation logic
• ➖ Opinionated workflow; may not map cleanly to label-driven bumps
• ➖ Additional bot/configuration and potential repo noise (release PRs)

3. Single workflow triggered by release creation (not workflow_run)

• ➕ Clearer trigger semantics: binaries build only when a release exists
• ➕ Avoids coupling to Auto Release job naming/conclusion
• ➖ More moving parts (needs release event handling and ref resolution)
• ➖ Manual rerun/recovery flows can be trickier than explicit dispatch input

Recommendation: The current approach is reasonable for a label-driven release process, and it correctly handles key GitHub Actions constraints (GITHUB_TOKEN tag push not triggering tag workflows) by chaining via workflow_run and serializing with concurrency groups. If this repo expects frequent releases or more platforms/signing in the future, consider migrating the binary packaging portion to GoReleaser while keeping the PR-label gate and module-path guard as policy checks.

Files changed (6) +496 / -0

Enhancement (1) +10 / -0

main.goAdd -version flag and ldflags-populated build version string +10/-0

Add -version flag and ldflags-populated build version string

• Adds a main.version variable defaulting to "dev" and a -version flag that prints the daemon name plus version and exits. This enables release builds to embed the tag via -ldflags "-X main.version=vX.Y.Z" and supports binary smoke testing in CI.

cmd/mcpproxyd/main.go

Documentation (1) +30 / -0

README.mdDocument the CI-driven release process and how Go module tags work +30/-0

Document the CI-driven release process and how Go module tags work

• Adds documentation describing label-driven semver bumping, CI-created tags/releases, binary artifact naming/contents, the manual republish path, and the Go module import-path requirement for v2+ releases.

README.md

Other (4) +456 / -0

auto-release.ymlAdd auto-tagging and GitHub release creation on main merges +147/-0

Add auto-tagging and GitHub release creation on main merges

• Introduces an Auto Release workflow that finds the merged PR for a main push, enforces a major/minor/patch/skip-release label policy, computes the next semver tag from existing releases, guards against invalid v2+ Go module paths, and creates a GitHub release/tag via gh. Adds concurrency to prevent back-to-back merges racing on tag selection and release creation.

.github/workflows/auto-release.yml

binary-release.ymlPublish cross-platform binary archives to each GitHub release +175/-0

Publish cross-platform binary archives to each GitHub release

• Adds a Binary Release workflow triggered by Auto Release completion (and a manual dispatch escape hatch) to resolve the released tag/ref, cross-compile the four commands for multiple OS/arch targets, package README/config/examples, generate checksums, smoke-test the linux/amd64 artifact, and upload assets to the existing GitHub release.

.github/workflows/binary-release.yml

pr-label-check.ymlEnforce exactly one release label on every PR +38/-0

Enforce exactly one release label on every PR

• Adds a PR workflow that uses the GitHub CLI to verify the PR has exactly one of: major, minor, patch, or skip-release. Fails early to ensure merges do not bypass the release bump policy expected by Auto Release.

.github/workflows/pr-label-check.yml

test.ymlAdd CI for formatting, tidiness, tests, builds, and example config validation +96/-0

Add CI for formatting, tidiness, tests, builds, and example config validation

• Introduces a Test workflow that runs gofmt and go mod tidy checks, go vet and go test -race, cross-platform build matrix vet/build for multiple GOOS/GOARCH targets, and validates shipped example YAML configs via the configcheck tool with placeholder env vars.

.github/workflows/test.yml

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Release list truncated ✓ Resolved 🐞 Bug ≡ Correctness

Description

Auto Release only considers the most recent 30 releases when computing the highest existing semver
tag, so a higher-but-older semver release can be missed and the workflow can compute an incorrect
NEXT version (potentially colliding and then failing release creation). This is caused by the `gh
release list -L 30` bound in the version calculation step.

Code

.github/workflows/auto-release.yml[R84-88]

+          LATEST=$(gh release list -L 30 --json tagName --jq '
+            [.[].tagName | select(test("^v[0-9]+\\.[0-9]+\\.[0-9]+$"))]
+            | sort_by(sub("^v"; "") | split(".") | map(tonumber))
+            | .[-1] // ""
+          ')

Evidence

The workflow bounds version discovery to 30 releases, then derives NEXT from that subset; if the
true highest semver release is not in that subset, NEXT is computed from the wrong base and the
later “already exists” guard can fail the run.

.github/workflows/auto-release.yml[84-100]
.github/workflows/auto-release.yml[136-139]
.github/workflows/auto-release.yml[23-27]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Auto Release computes `LATEST` from only the most recent 30 GitHub releases (`gh release list -L 30`). If a higher semver release is older than the 30 most recently created releases (e.g., out-of-order publishing / backports / hotfixes created after a major bump), `LATEST` can be wrong and `NEXT` can collide or regress.

### Issue Context
The workflow already checks out with `fetch-depth: 0`, so all tags are available locally.

### Fix Focus Areas
- .github/workflows/auto-release.yml[23-27]
- .github/workflows/auto-release.yml[80-105]

### Suggested fix
Replace the release-list-based discovery with a local tag-based semver max (or paginate all releases).

Example (tag-based):
```bash
LATEST=$(git tag -l 'v[0-9]*.[0-9]*.[0-9]*' --sort=v:refname | tail -n 1)
[ -z "$LATEST" ] && LATEST="v0.0.0"
```
This avoids arbitrary truncation and keeps version selection stable as release history grows.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Go version duplicated ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

Multiple workflows hardcode go-version: "1.26" instead of reading from go.mod, so updating the
module’s Go version later can leave CI/release using a different toolchain than intended. This
duplication makes upgrades easy to miss and increases CI drift risk.

Code

.github/workflows/test.yml[R17-20]

+      - uses: actions/setup-go@v5
+        with:
+          go-version: "1.26"
+      - name: Check formatting

Evidence

go.mod declares the repo’s Go version, but the new workflows each pin a separate literal value; this
introduces multiple sources of truth.

go.mod[1-4]
.github/workflows/test.yml[16-20]
.github/workflows/auto-release.yml[28-32]
.github/workflows/binary-release.yml[110-113]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Workflows repeat the Go version in several places (`go-version: "1.26"`). This is easy to forget to update when `go.mod` changes.

### Issue Context
`actions/setup-go` supports `go-version-file: go.mod`, which centralizes the version source.

### Fix Focus Areas
- .github/workflows/test.yml[17-20]
- .github/workflows/test.yml[46-49]
- .github/workflows/test.yml[74-77]
- .github/workflows/test.yml[93-96]
- .github/workflows/auto-release.yml[28-32]
- .github/workflows/binary-release.yml[110-113]

### Suggested fix
In every `actions/setup-go@v5` step, replace:
```yaml
with:
 go-version: "1.26"
```
with:
```yaml
with:
 go-version-file: go.mod
```
This keeps CI/release aligned with the module’s declared toolchain intent.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}