Repository navigation
Release both gems from single-job workflows (add structured_params-openapi release) - #24
Conversation
- release-openapi.yml publishes the gem when a GitHub Release tagged openapi-vX.Y.Z is published: it sets VERSION, prepends the release notes to structured_params-openapi/CHANGELOG.md, commits to main, builds the gem and runs rubygems/release-gem from structured_params-openapi/ - structured_params-openapi/Rakefile provides build/release tasks that tag releases with the openapi- prefix, so they never collide with the core gem's vX.Y.Z tags - release.yml now ignores openapi-v* releases - add structured_params-openapi/CHANGELOG.md and ship it in the gem - document releasing both gems in CONTRIBUTING.md Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
|
Note Currently processing new changes in this PR. This may take a few minutes, please wait... ⚙️ Run configuration
📒 Files selected for processing: 8
✨ Finishing Touches
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. Comment |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2b66303b90
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
tagging.yml (version bump on a v* tag) and release.yml (CHANGELOG, build, publish on a published Release) ran concurrently: release.yml's checkout of main had to land after the version commit, which for v0.9.5 happened within the same second. The workflow_run trigger meant to order them never fired (its branches: [main] filter does not match a tag push). Merge them into one sequential job, as release-openapi.yml does: set VERSION, prepend the release notes to structured_params/CHANGELOG.md, commit once to main, then build and publish. Pass untrusted release text through env: instead of interpolating it into the script. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Address the review of the single-job release workflows: - validate the Release tag (vX.Y.Z / openapi-vX.Y.Z), that its commit is on main and that the version does not go backwards; assert that the VERSION substitution applied - skip the CHANGELOG entry when the version is already there, so a re-run does not duplicate it; normalize CRLF in the release notes - build the gem before pushing to main, so a failure leaves main untouched - ignore pre-releases and share a concurrency group between the two workflows - document releasing in CONTRIBUTING.md (what CI writes, re-runs, Trusted Publisher setup, the tag pointing before the version commit) and fix stale paths in AGENTS.md and copilot-instructions.md Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
A Release creates its tag before the workflow commits the version and CHANGELOG, so the tag did not contain what was built and published. After pushing that commit to main, move the Release's tag onto it (before publishing, so a refused tag push fails the job with nothing released). rake release then finds the tag and only builds and pushes the gem. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Summary
Follow-up to #22 and #23. Add a release flow for the
structured_params-openapigem, which until now could not be published.openapi-vX.Y.Zreleasesstructured_params-openapi;vX.Y.Zreleases the core gem.structured_params-openapi/RakefilesetsBundler::GemHelper#tag_prefix = 'openapi-'.release.yml,release-openapi.yml;tagging.ymlis removed). On a published, non-pre-release Release the job: validates the tag (X.Y.Z, commit onmain, version not going backwards), setsVERSION(asserting it applied), prepends the notes to the gem'sCHANGELOG.md(idempotent, CRLF normalized), commits, builds the gem, pushes tomain, moves the Release's tag onto the pushed commit, then publishes withrubygems/release-gem(working-directory, Trusted Publishing). A failure before the push leavesmainuntouched, and a failed run can be re-run.tagging.ymlwent: it ran concurrently withrelease.yml; for v0.9.5 the version commit finished at 06:50:34 and the release checkout started the same second. Theworkflow_runtrigger meant to order them never fired (no such run in the history).concurrencygroup (both push tomain), pass untrusted release text throughenv:, and ignore pre-releases and the other gem's tags.CHANGELOG.mdand achangelog_uri;CONTRIBUTING.mddocuments releasing both gems, re-runs and the Trusted Publisher setup; stale paths inAGENTS.mdandcopilot-instructions.mdare fixed.How to release (after merge)
openapi-v0.1.0targetingmain, and write the notes.One-time setup before the first release (maintainer)
Register a (pending) Trusted Publisher on rubygems.org for
structured_params-openapi: repositorySyati/structured_params, workflowrelease-openapi.yml. Without it the publish step fails.Validation
bundle exec rake: RSpec core 183 +structured_params-openapi84 examples, RuboCop, Steep pass; lefthook pre-commit passesv0.3,-rc1,foo, empty), a downgrade, a tagged commit that is not onmain, and the tag move against a bare remoterake releaseinstructured_params-openapi/resolves the tag toopenapi-v0.1.0Not verified
The workflows cannot run until a Release is published, so the end-to-end path on GitHub (Trusted Publishing,
rake releaseskipping the existing tag, the tag force-push being allowed by any tag protection rules) is untested; the first real release of each gem is the test. The old two-workflow core flow did work for v0.9.0-v0.9.5, so please review the rewrittenrelease.ymlwith that in mind. Commit messages change from two (Update version to X,Update CHANGELOG for vX) to one (Update structured_params to X).🤖 Generated with Claude Code