chore: add workflow to enforce Conventional Commit tags #338
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This workflow checks the PR title, not the commit messages, so adding the Conventional Commit tag can be done by editing the PR title without making any changes to the commits in the PRs. When a PR is opened without Conventional Commit tags, the workflow adds a comment to the PR that explains what the issue is and how to fix it (screenshot below is taken from equinix-labs/metal-go#134: When the PR title is updated to fix the issue, the comment is deleted. By enforcing tags on the PR titles, we make it possible for internal people to add the necessary tags if, for example, we get a good PR from an external contributor and that contributor is not motivated to add the necessary tag or picks the wrong tag. |
ctreatma
force-pushed
the
conventional-commits
branch
from
a7e3ded to
83650b5
Compare
displague
approved these changes
Sep 8, 2023
ocobles
pushed a commit
that referenced
this pull request
Nov 10, 2023
Currently our release process is fairly manual: someone with write access to this repo has to check out the latest from `main`, look at what has changed since the last release, decide on an appropriate new version number, create a git tag in the correct format (is it `x.y.z` or `vx.y.z`?), and push that tag back up to GitHub to trigger the release process. By ensuring that our PR titles have Conventional Commit tags, we make it possible to automatically determine the next release version number, which means we can move to a push-button release process: click the release button, and the workflow does the rest. This workflow has been in place for some time on `metal-go` and was recently adopted in `metal-java`; adopting it more broadly will make it easier for us to safely share the responsibility for releasing our various tools (and could even lead to automated / scheduled release workflows instead of push-button workflows).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently our release process is fairly manual: someone with write access to this repo has to check out the latest from
main, look at what has changed since the last release, decide on an appropriate new version number, create a git tag in the correct format (is itx.y.zorvx.y.z?), and push that tag back up to GitHub to trigger the release process.By ensuring that our PR titles have Conventional Commit tags, we make it possible to automatically determine the next release version number, which means we can move to a push-button release process: click the release button, and the workflow does the rest.
This workflow has been in place for some time on
metal-goand was recently adopted inmetal-java; adopting it more broadly will make it easier for us to safely share the responsibility for releasing our various tools (and could even lead to automated / scheduled release workflows instead of push-button workflows).