chore: crates.io badges, README accuracy, release-plz migration#20
Conversation
- Add version, docs.rs, CI, downloads, and license badges. - Fix config examples to match the actual schema: upstream.default (not .address), descriptors list (not descriptor), listen.http, cors.origins, real shield fields. - Fix Library Usage to the real API (ProxyServer::from_config().serve() / .router()); the previous build_proxy function does not exist. - Drop the "gRPC reflection" descriptor option from docs (the loader warns and ignores it) and the unimplemented query-param claim. - Split Features into what is actually wired vs a Roadmap section, and tag the shield/auth/oidc_discovery config blocks as roadmap (parsed but not yet enforced) so nothing is dropped from the spec. Part of #19
- Trim ci.yml to the quality-checks job (fmt, clippy, build, test,
publish dry-run) that runs on PRs and pushes.
- Add release-plz.yml: a release-pr job that opens/updates a release PR
(version bump + CHANGELOG from conventional commits) and a release job
that tags, creates the GitHub release, and publishes to crates.io on
merge. Reuses the existing GitHub App token and crates.io OIDC
trusted publishing.
- Add release-plz.toml pinning the tag scheme to v{version} to keep tag
history continuous with the previous tags.
- Remove .releaserc.json (semantic-release config).
Part of #19
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughSummary by CodeRabbitRelease Notes
WalkthroughReplaces the semantic-release pipeline with release-plz by adding a new GitHub Actions workflow for release PR creation and crates.io OIDC trusted publishing, pins action versions and removes the ChangesRelease pipeline migration
README accuracy and roadmap clarification
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
| Filename | Overview |
|---|---|
| .github/workflows/ci.yml | Removes the semantic-release and crates-publish jobs, retaining only the quality-checks job; pins Swatinem/rust-cache to a SHA per zizmor policy. |
| .github/workflows/release-plz.yml | New release-plz workflow with two jobs (release-pr, release); both have owner guards, concurrency groups, least-privilege app tokens, and OIDC crates.io auth. Previously flagged issues (concurrency guard on release job) have been resolved in 94fcf05. |
| .github/zizmor.yml | Defines action-pinning policy: ref-pin for trusted publishers (actions/, rust-lang/, release-plz/, dtolnay/, etc.), hash-pin for everything else. |
| README.md | Major accuracy overhaul: corrects config schema keys, fixes library API (ProxyConfig/ProxyServer replacing nonexistent build_proxy), moves unimplemented features to a Roadmap section, and adds crates.io ecosystem badges. |
| release-plz.toml | New file pinning the tag scheme to v{version} to keep tag history continuous with the previous semantic-release format. |
| .greptile/config.json | Adds the no-sha-pin-trusted-actions review rule scoped to workflow files, codifying the zizmor policy for Greptile reviews. |
| .releaserc.json | File deleted as part of the semantic-release → release-plz migration. |
Reviews (4): Last reviewed commit: "ci: narrow trusted googleapis scope to r..." | Re-trigger Greptile
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/release-plz.yml:
- Around line 48-55: The release job is missing concurrency control which allows
multiple release jobs to run concurrently when successive pushes occur to main,
risking tag and publish races. Add a concurrency block to the release job (after
the if: condition) similar to what exists in the release-pr job, using the same
group name and cancel-in-progress setting to ensure only one release process
runs at a time.
- Around line 27-30: The GitHub App token generation steps in the release-plz
workflow are missing explicit permission constraints, causing them to inherit
all permissions granted to the GitHub App installation by default. Add explicit
`permission-*` inputs to both token creation steps to scope permissions to the
minimum required: in the first job (release-pr workflow), add
`permission-contents: write` and `permission-pull-requests: write` to the token
creation step that uses the RELEASER_APP_ID and RELEASER_APP_PRIVATE_KEY
secrets, and in the second job (release workflow), add `permission-contents:
write` to its corresponding token creation step at lines 60-63.
- Line 24: All workflow action references in the release-plz.yml file are using
mutable version tags or branches instead of immutable commit SHAs. Replace each
`uses:` statement that references `create-github-app-token@v3`, `checkout@v6`,
`dtolnay/rust-toolchain@stable`, `release-plz/action@v0.5`, and
`crates-io-auth-action@v1` with their corresponding full commit SHA followed by
a comment indicating the tag (for example:
`actions/checkout@a5ac7e51b41094c153da5fb481531c5d0bd51efb # v6`). You will need
to look up the commit SHA for each action version from their respective releases
or tags and update all 9 occurrences across both the build and publish jobs.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: ba7d617c-61bf-4969-b43a-3ee34d532d69
📒 Files selected for processing (5)
.github/workflows/ci.yml.github/workflows/release-plz.yml.releaserc.jsonREADME.mdrelease-plz.toml
💤 Files with no reviewable changes (1)
- .releaserc.json
- README: the `cors.origins: ["*"]` example was misleading. build_cors() uses permissive CORS only for an empty list; a non-empty list does exact origin matching, so "*" (which browsers never send as Origin) would block every cross-origin request. Show `origins: []` for dev and an explicit-origins example instead. - release-plz.yml: add a concurrency guard to the release job so two pushes landing together cannot both tag and publish the same version. Part of #19
- Pin every third-party action to an immutable commit SHA (with a # vN comment dependabot keeps fresh) across both workflows. The deliberately-rolling dtolnay/rust-toolchain@stable is left as a branch ref and is already excluded from dependabot. - Scope the GitHub App tokens to least privilege: release-pr gets contents+pull-requests write, release gets contents write, instead of inheriting all installation permissions. Part of #19
Refine the action-pinning approach: trusted publishers (GitHub-official, Rust-official, the release tooling we depend on) keep tag/branch refs; only third-party actions are pinned to a commit SHA. In practice this un-pins actions/*, release-plz/*, and rust-lang/* back to tags and keeps only Swatinem/rust-cache on a SHA. Encode the policy so the reviewers stop flagging trusted-org tag refs: - .github/zizmor.yml: unpinned-uses policies — ref-pin for the trusted orgs, hash-pin for everything else (this is the source of the CodeRabbit finding). - .greptile/config.json: a matching rule scoped to workflow files. Part of #19
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/zizmor.yml:
- Around line 15-17: The zizmor.yml configuration file currently allows all
googleapis actions to use ref-pin via the pattern googleapis/*, which is overly
broad and conflicts with the security policy documented in .greptile/config.json
that restricts trusted Google actions to googleapis/release-please*. Change the
googleapis/* pattern to googleapis/release-please* to narrow the trusted scope
and align with the documented security boundary, ensuring only the intended
release-please action bypasses hash-pinning while other googleapis actions
remain subject to the default hash-pin requirement.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 4ae98d98-94fe-456f-8bfd-0e9e8d2b40f3
📒 Files selected for processing (4)
.github/workflows/ci.yml.github/workflows/release-plz.yml.github/zizmor.yml.greptile/config.json
zizmor.yml trusted googleapis/* broadly while .greptile/config.json only trusts googleapis/release-please*. Align both: restrict the ref-pin exemption to release-please so any other googleapis action still falls under the hash-pin default. Part of #19
Summary
Repo maintenance, no product code. Two concerns, separate commits.
docs(readme)
upstream.default(not.address),descriptorslist (notdescriptor),listen.http,cors.origins, realshieldfields.ProxyServer::from_config().serve()/.router(); the documentedbuild_proxynever existed.[roadmap].ci: semantic-release → release-plz
ci.ymltrimmed to the quality-checks job (fmt, clippy, build, test, publish dry-run).release-plz.yml:release-prjob (opens/updates a release PR with version bump + CHANGELOG) andreleasejob (tag + GitHub release + crates.io publish on merge). Reuses the existing GitHub App token and crates.io OIDC trusted publishing.release-plz.tomlpins the tag scheme tov{version}so tag history stays continuous..releaserc.json.Release-flow note (sequencing with #18)
This swaps the release mechanism. After merge, releases happen via a release PR instead of auto-on-merge. If #18 (the axum fix) merges before this, semantic-release still cuts 1.0.3 as planned. If this merges first, release-plz will open a release PR for the pending fix instead. Either order is fine; just flagging the behavior change.
Verification
Closes #19