-
-
Notifications
You must be signed in to change notification settings - Fork 91
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
Swap release process to release-please #506
Comments
Thoughts @scagood @aladdin-add @brettz9? |
Looks all right to me... |
I do much prefer release-please as:
(Also, its just personal comfort 😂) It does have some down sides, such as merge commits occasionally create double entries in the change log. |
Between |
Yeah, one should preferably only do squash (or rebase commits) with it |
Currently, it appears that only |
That's good 👍 |
**What is the purpose of this pull request?** To improve the release process by swapping to release-please. Fixes #506 **What changes did you make? (Give an overview)** Removed `cycjimmy/semantic-release-action` and added `googleapis/release-please-action`
**What is the purpose of this pull request?** To assist #508 / #506 by ensuring that PR-title's are always valid conventional commit format before merging **What changes did you make? (Give an overview)** Added a pinned [mtfoley/pr-compliance-action](https://github.com/mtfoley/pr-compliance-action) similar to what I use at eg. neostandard: https://github.com/neostandard/neostandard/blob/main/.github/workflows/compliance.yml
I would personally be in favor of switching to a release please flow, like in eslint-community/eslint-plugin-n#305, as that catches errors like this before release
This would help catch release errors like #484 (comment) before they actually get released
The text was updated successfully, but these errors were encountered: