Skip to content

Automate Releases with release-please-action #791

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
jcouball opened this issue May 14, 2025 · 5 comments
Closed

Automate Releases with release-please-action #791

jcouball opened this issue May 14, 2025 · 5 comments

Comments

@jcouball
Copy link
Member

jcouball commented May 14, 2025 •
edited
Loading

Enforce Conventional Commits, Add Automatic Changelog Generation, and Implement a CD Workflow

Currently, ruby-git utilizes the create-github-release script for new releases. This is documented in the RELEASING.md document. This approach has several drawbacks:

  • Determining the appropriate release type (major, minor, or patch) can be challenging without intimate familiarity with every merged pull request (PR).
  • After the create-github-release script defines a release, incorporating additional PRs into that release is a manual and error-prone process.
  • The release PR must be merged from a developer's local machine.
  • Pushing the new gem to rubygems.org is a manual step.

To address these issues and streamline the release process, I propose integrating the googleapis/release-please-action. This would enable automated Continuous Delivery releases with the following benefits:

  • Automated Release PR Creation: A release PR will be automatically generated when a PR is merged into master branch. This PR will update the changelog and version number appropriately, based on the commits since the last release.
  • Dynamic Release PR Updates: While a release PR is open, any subsequent PRs merged into master will be automatically added to the existing release PR. The version bump will be adjusted dynamically based on Conventional Commit messages.
  • Automated Publishing: When the release PR is merged into master, the version will be officially bumped, and a new version of the gem will be built and published to rubygems.org.

For this automation to function correctly, all commits moving forward must adhere to the Conventional Commits format. To enforce this, I propose adding a GitHub Actions workflow that validates commit messages. PRs with improperly formatted commit messages will fail checks, blocking them from being merged.

Additionally, I suggest integrating an optional pre-commit hook. Developers can install this hook locally to automatically check and reject commits that do not conform to the required format before they are pushed.

I have written in more detail about integrating release-please-action in a Substack article: Continuous Delivery for Ruby Gems.

An example of this integrated system can be seen in the process_executer gem. Specifically, note the automatically generated CHANGELOG.md and an example release PR.
@jcouball
Copy link
Member Author

@mpapis since I have your ear today, I was wondering if I could get your feedback on this proposal at your convenience.

This was referenced May 15, 2025
Merged
Merged
Merged
@mpapis
Copy link
Contributor

mpapis commented May 15, 2025 •
edited
Loading

It's definitively really good direction, automate everything :)

I was actually reading your flow recently and had went a bit different route:

  • use branch prefix to automatically create PR labels
    • enforce one_of labels to prevent merging PR before it's properly labeled
    • I can change the labels when I think the change has different effect on release
  • generate changelog summary on every merge to master (or develop in my case) - this step is similar: grouping PR's by their labels
  • separate action to release, I took a shortcut and do not even create a PR, I can check changelog on any merged PR's CI summary, when I'm satisfied with the release - I trigger the release workflow with Run workflow
  • enforce CI with branch rules on github ... for now I've disabled it as I was working on the workflows and needed to play with few things, but as soon as external contributors show up I will enable it for sure :) ... what's inconvenient with branch rulesets is that it's out of code and I'm looking forward for github allowing configure required checks in the repo itself

I think both approaches are very similar, with different strains on maintainers and one time developers. In my experience enforcing rules on rare contributors might discourage contribution, so in my flow the strain of properly marking the impact on release is moved to maintainer with PR labels - of course convenience of auto-labeling from branch prefixes is useful, but not required on one-time developers to adhere to complex rules and understanding the overall impact.

I plan to extract my workflow to actions for others to make use of it too: mpapis/uncov#55

@jcouball
Copy link
Member Author

I share your concern about strains on rare contributors.

Despite that, I went ahead and implemented this. I plan on putting a paragraph or two toward the top of the README announcing this and setting expectations. We will see how it goes.

I'll keep an eye on your workflow actions.

@jcouball jcouball mentioned this issue May 15, 2025
Merged
@jcouball
Copy link
Member Author

jcouball commented May 15, 2025 •
edited
Loading

I updated the README with an announcement banner front and center.

The Commit Message Guidelines in the CONTRIBUTING doc has the details.

@mpapis
Copy link
Contributor

mpapis commented May 20, 2025

Looks nice :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@mpapis @jcouball