Skip to content

Release both gems from single-job workflows (add structured_params-openapi release) - #24

Merged
Syati merged 6 commits into
mainfrom
ci/release-openapi-gem
Oct 13, 2026
Merged

Syati merged 6 commits into
mainfrom
ci/release-openapi-gem

Conversation

@Syati

@Syati Syati commented Oct 12, 2026 •

Copy link
Copy Markdown
Owner

Summary

Follow-up to #22 and #23. Add a release flow for the structured_params-openapi gem, which until now could not be published.

Stacked on #23. The base is refactor/core-gem-folder. Retarget to main once #22 and #23 are merged.

  • Tag scheme: a Release tagged openapi-vX.Y.Z releases structured_params-openapi; vX.Y.Z releases the core gem. structured_params-openapi/Rakefile sets Bundler::GemHelper#tag_prefix = 'openapi-'.
  • One sequential job per gem (release.yml, release-openapi.yml; tagging.yml is removed). On a published, non-pre-release Release the job: validates the tag (X.Y.Z, commit on main, version not going backwards), sets VERSION (asserting it applied), prepends the notes to the gem's CHANGELOG.md (idempotent, CRLF normalized), commits, builds the gem, pushes to main, moves the Release's tag onto the pushed commit, then publishes with rubygems/release-gem (working-directory, Trusted Publishing). A failure before the push leaves main untouched, and a failed run can be re-run.
  • Why tagging.yml went: it ran concurrently with release.yml; for v0.9.5 the version commit finished at 06:50:34 and the release checkout started the same second. The workflow_run trigger meant to order them never fired (no such run in the history).
  • Both workflows share a concurrency group (both push to main), pass untrusted release text through env:, and ignore pre-releases and the other gem's tags.
  • The gem ships CHANGELOG.md and a changelog_uri; CONTRIBUTING.md documents releasing both gems, re-runs and the Trusted Publisher setup; stale paths in AGENTS.md and copilot-instructions.md are fixed.

How to release (after merge)

  1. Create a GitHub Release with a new tag openapi-v0.1.0 targeting main, and write the notes.
  2. The workflow does the rest.

One-time setup before the first release (maintainer)

Register a (pending) Trusted Publisher on rubygems.org for structured_params-openapi: repository Syati/structured_params, workflow release-openapi.yml. Without it the publish step fails.

Validation

  • bundle exec rake: RSpec core 183 + structured_params-openapi 84 examples, RuboCop, Steep pass; lefthook pre-commit passes
  • The shell steps were run locally against a throwaway repository: a valid release, a re-run (no duplicate entry, no new commit), bad tags (v0.3, -rc1, foo, empty), a downgrade, a tagged commit that is not on main, and the tag move against a bare remote
  • All workflow files parse as YAML; rake release in structured_params-openapi/ resolves the tag to openapi-v0.1.0

Not verified

The workflows cannot run until a Release is published, so the end-to-end path on GitHub (Trusted Publishing, rake release skipping 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 rewritten release.yml with 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

- 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>
@coderabbitai

coderabbitai Bot commented Oct 12, 2026 •

Copy link
Copy Markdown

Review in Change Stack →

Note

Currently processing new changes in this PR. This may take a few minutes, please wait...

⚙️ Run configuration
  • Configuration used: defaults
  • Review profile: CHILL
  • Plan: Advanced
  • Run ID: 42846f1b-4087-4714-be0f-5e96c0e53e76
📥 Commits

Reviewing files that changed from the base of the PR and between 80e8ad6 and 7fcc69e.

📒 Files selected for processing: 8
  • .github/copilot-instructions.md
  • .github/workflows/release-openapi.yml
  • .github/workflows/release.yml
  • .github/workflows/tagging.yml
  • CONTRIBUTING.md
  • structured_params-openapi/CHANGELOG.md
  • structured_params-openapi/Rakefile
  • structured_params-openapi/structured_params-openapi.gemspec
 __________________________________________________
< Deploying the charm offensive against your bugs. >
 --------------------------------------------------
  \
   \   (\__/)
       (•ㅅ•)
       /   づ
✨ Finishing Touches
📝 Generate docstrings
  • Commit to this branch
  • Create a new PR
🧪 Generate unit tests (beta)
  • Commit to this branch
  • Create a new PR
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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

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

@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Oct 12, 2026 •

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review ✅ Completed 2026-10-12T11:33:16.895354Z 2b66303 PR opened
ℹ️ 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" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 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".

Comment thread .github/workflows/release-openapi.yml
Comment thread .github/workflows/release-openapi.yml
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>
@Syati Syati changed the title Add a release workflow for the structured_params-openapi gem Release both gems from single-job workflows (add structured_params-openapi release) Oct 12, 2026
Syati and others added 4 commits October 12, 2026 21:15
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>
@Syati
Syati changed the base branch from refactor/core-gem-folder to main October 13, 2026 22:03
@Syati
Syati merged commit a7550a2 into main Oct 13, 2026
10 of 11 checks passed
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