-
Notifications
You must be signed in to change notification settings - Fork 155
chore(ci): add versioning workflow for pre-release #2006
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.
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for working on this. Looks great and I have tested it in a fork.
Would like to hear from @sthulb if we could move this action (aka only what's under .github/actions/create-pr
) under the dedicated actions
repo we have in the org.
This action is an almost exact copy of the one here from the Python repo. The changes we made here should be able to be refactored so that they're parameters/inputs of the action.
This way we can have a single place & maintain only once rather than have the same / slightly similar action in two projects.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for raising the bar on this!
Description of your changes
This PR adds a workflow to run versioning before a release, which solves two issues. 1/
lerna version
does not push the commit back tomain
, 2/ we can review version and changelog changes before the release, avoiding accidentally wrong version bumps based on conventional commits.While we previously had a tag during versioning, I suggest keeping the tag after a successful package publish step in the release workflow.
Related issues, RFCs
Issue number: #1799
Checklist
Breaking change checklist
Is it a breaking change?: NO
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.