build: semi-automated release process#80
Conversation
Up to standards ✅🟢 Issues
|
f94b6a6 to
e19047f
Compare
Signed-off-by: Amauri Bizerra <10775696+extern-c@users.noreply.github.com>
Signed-off-by: Amauri Bizerra <10775696+extern-c@users.noreply.github.com>
Signed-off-by: Amauri Bizerra <10775696+extern-c@users.noreply.github.com>
Signed-off-by: Amauri Bizerra <10775696+extern-c@users.noreply.github.com>
There was a problem hiding this comment.
the release process looks very promising. 👍
Release documentation will be added in a follow-up PR.
Docs shall happen when changes happen.
Could you please add some docs how this all works and how it is triggered?
This might go here: CONTRIBUTING.md section "To release a new version".
You might want to remove the "Manual process" and add a "Semi-Automated process" or whatever sounds appropriate
please also add a description of the build changes to CHANGELOG.md
| needs: rubygems_release | ||
| environment: release | ||
| permissions: | ||
| contents: write |
There was a problem hiding this comment.
please add a comment why this permission is needed
There was a problem hiding this comment.
Addressed in e3c2541. Thanks for the suggestion.
| timeout-minutes: 10 | ||
| needs: test | ||
| permissions: | ||
| contents: write |
There was a problem hiding this comment.
please add comments why the permissions are needed
There was a problem hiding this comment.
Addressed in 51b50f1. Thanks for the suggestion.
| persist-credentials: false | ||
| - name: Create GitHub Release | ||
| run: | | ||
| gh release create "${{ github.ref_name }}" \ |
There was a problem hiding this comment.
| gh release create "${{ github.ref_name }}" \ | |
| gh release create "$GITHUB_REF_NAME" \ |
see
There was a problem hiding this comment.
Addressed in 2106cb1. Thanks for the suggestion.
| with: | ||
| persist-credentials: false | ||
| - name: Create GitHub Release | ||
| run: | |
There was a problem hiding this comment.
please rework this to
run: >
gh release create ...
--verify-tag
...| ruby-version: ruby | ||
| bundler-cache: false | ||
| - name: "Push gem to RubyGems" | ||
| uses: rubygems/release-gem@6317d8d1f7e28c24d28f6eff169ea854948bd9f7 # v1.2.0 |
There was a problem hiding this comment.
please add a comment with the action's URL for easier docks lookup when maintaining.
There was a problem hiding this comment.
Addressed in da61dd3. Thanks for the suggestion.
| run: | | ||
| gh release create "${{ github.ref_name }}" \ | ||
| --verify-tag \ | ||
| --generate-notes |
There was a problem hiding this comment.
I'd love to see the "--prerelease" marker in case the tag looks like one.
This will be especially needed to test the release process before merging the PR.
Possible way to do this: similar to https://github.com/CycloneDX/cyclonedx-buildroot/blob/main/.github/workflows/release.yml
- add a new job that determines whether this is a prerelease
- do a pattern-math on the version string
- set an output parameter properly
- have the release process depend on the newly added job
- when creating the GH release: reflect on the outcome and flag as prerelease if needed
|
|
||
| on: | ||
| push: | ||
| tags: ["v*"] |
There was a problem hiding this comment.
maybe better go with
| tags: ["v*"] | |
| tags: ["v*.*.*"] |
There was a problem hiding this comment.
Addressed in 3e9e0ba. Thanks for the suggestion.
| uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0 | ||
| with: | ||
| persist-credentials: false | ||
| - name: Create GitHub Release |
There was a problem hiding this comment.
could the release have the gem as a release asset?
It would be ideal to use the one produced in the rubygems_release job - you could use https://docs.github.com/en/actions/concepts/workflows-and-actions/workflow-artifacts to transfer a file from one job to the other. (artifact lifetime of 1 day should be enough)
There was a problem hiding this comment.
Would you be okay with deferring this for now? I don't think it's necessary to include the built gem in the GitHub release since it'll already be published to RubyGems, and anyone can build it from the release assets. AFAIK, rubygems/release-gem does not produce a build artifact, so we'd need to add additional steps to build the gem and upload it separately.
There was a problem hiding this comment.
just artifact pkg/*.gem at the end of the rubygems_release should work, right?
I mean, rubygems/release-gem does not do any magic, it just calls bundle exec rake release which will cause emitting files pkg/*.gem.
see https://github.com/rubygems/release-gem/blob/052cc82692552de3ef2b81fd670e41d13cba8092/action.yml#L60-L67
There was a problem hiding this comment.
I rechecked the rubygems/release-gem behavior and think that the generated gem remains available after the release step, so it should be reusable as you suggested 👍. See commit 2af378b.
Signed-off-by: Amauri Bizerra <10775696+extern-c@users.noreply.github.com>
Signed-off-by: Amauri Bizerra <10775696+extern-c@users.noreply.github.com>
Signed-off-by: Amauri Bizerra <10775696+extern-c@users.noreply.github.com>
Signed-off-by: Amauri Bizerra <10775696+extern-c@users.noreply.github.com>
Signed-off-by: Amauri Bizerra <10775696+extern-c@users.noreply.github.com>
Signed-off-by: Amauri Bizerra <10775696+extern-c@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Adds a new GitHub Actions workflow to run tests and perform a semi-automated release flow on version tag pushes, targeting RubyGems (trusted publishing) and GitHub Releases.
Changes:
- Introduces a
Releaseworkflow triggered on version tag pushes. - Adds a
testjob that runs the rake default task on Ruby 3.3.9 before releasing. - Adds jobs to publish to RubyGems via trusted publishing and create a GitHub Release with generated notes.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
|
||
| on: | ||
| push: | ||
| tags: ["v*.*.*"] |
There was a problem hiding this comment.
The PR description has been updated to reflect the actual tag trigger.
| permissions: | ||
| contents: read |
| # see https://github.com/ruby/setup-ruby | ||
| uses: ruby/setup-ruby@9eb537ca036ebaed86729dcb9309076e4c5c3b74 # v1.314.0 | ||
| with: | ||
| ruby-version: ruby |
| timeout-minutes: 10 | ||
| needs: test | ||
| permissions: | ||
| contents: write # Required for `rake release` to perform git synchronization. |
There was a problem hiding this comment.
This is intentional. This CI job follows the rubygems/release-gem usage documentation. Although actions/checkout is configured with persist-credentials: false, the rubygems/release-gem action configures Git authentication itself using github.token (its token input defaults to ${{ github.token }}). See:
https://github.com/rubygems/release-gem#usage
https://github.com/rubygems/release-gem/blob/v1/action.yml#L10
Signed-off-by: Amauri Bizerra <10775696+extern-c@users.noreply.github.com>
Signed-off-by: Amauri Bizerra <10775696+extern-c@users.noreply.github.com>
|
will review in a week, please ping me if this is ready. |
| on: | ||
| push: | ||
| tags: ["v*.*.*"] | ||
|
|
There was a problem hiding this comment.
I believe bundle exec rake release already handles this case by checking whether the version tag exists before attempting to create it. See the relevant implementation in Bundler's GemHelper:
- https://github.com/ruby/rubygems/blob/v3.6.9/bundler/lib/bundler/gem_helper.rb#L67
- https://github.com/ruby/rubygems/blob/v3.6.9/bundler/lib/bundler/gem_helper.rb#L76.
So a workflow triggered by an existing tag shouldn't fail simply because the tag is already present.
| uses: ruby/setup-ruby@9eb537ca036ebaed86729dcb9309076e4c5c3b74 # v1.314.0 | ||
| with: | ||
| ruby-version: '3.4' # Stable environment to package the gem for the supported ruby versions | ||
| bundler-cache: false |
There was a problem hiding this comment.
I don't think this adds much value here, but let me know if you think it's worth pinning.
| # Determine release type from tag suffix | ||
| if [[ "$GITHUB_REF_NAME" =~ -(alpha|beta|rc|pre)[0-9.]*$ ]]; then | ||
| FLAGS+=("--prerelease") | ||
| fi |
There was a problem hiding this comment.
@jkowalleck, do you want to support dot-separated prerelease tags (e.g. v1.2.3.pre.1)?
Signed-off-by: Amauri Bizerra <10775696+extern-c@users.noreply.github.com>
Signed-off-by: Amauri Bizerra <10775696+extern-c@users.noreply.github.com>
Signed-off-by: Amauri Bizerra <10775696+extern-c@users.noreply.github.com>
I've updated |
Signed-off-by: Amauri Bizerra <10775696+extern-c@users.noreply.github.com>
Signed-off-by: Amauri Bizerra <10775696+extern-c@users.noreply.github.com>
@jkowalleck, this is now ready for review. |
Description
Add a release workflow for RubyGems and GitHub Releases triggered by version tags (
v*.*.*).This PR resolves issue: #46.
The workflow consists of three jobs:
The GitHub Release does not include a built gem package and is intended only for release metadata and assets.Future Improvements
To keep this change focused, a few related enhancements are left for follow-up work:
Document the release process (e.g. updating the gem version, creating and publishing a release tag, and publishing a release).UpdatedCONTRIBUTING.mdin commit 5545c7c.Release documentation will be added in a follow-up PR.Testing
The workflow has been validated to the extent possible, but I was unable to perform an end-to-end test for the RubyGems publishing step because trusted publishing requires maintainer-controlled RubyGems and repository configuration.
A maintainer will need to:
releaseenvironment if one does not already exist.AI Tool Disclosure
[e.g. GitHub CoPilot, ChatGPT, JetBrains Junie etc.][e.g. GPT-4.1, Claude Haiku 4.5, Gemini 2.5 Pro etc.][Summarize the key prompts or instructions given to the AI tools]Affirmation