-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
meta: add release-please-action
for automated releases
#2395
Conversation
Matches the formatting that release-please produces. Using the same formatting for previous entries prevents release-please from overwriting (deleting) previous entries when it updates the CHANGELOG.
Automatically creates/updates release PRs when there are new commits on a given branch of the repository (currently configured as `master`). Semver hints in commit messages can let release-please know whether to draft a minor or major release, but otherwise the release proposal PR will be for a semver patch-level release by default. Co-authored-by: gengjiawen <technicalcute@gmail.com>
Link to the "How should I write my commits?" section of release-please's README.md, rather than the NodeJS commit guidelines.
- [ ] commit message follows [commit guidelines](https://github.com/nodejs/node/blob/master/doc/guides/contributing/pull-requests.md#commit-message-guidelines) | ||
- [ ] commit message follows [commit guidelines](https://github.com/googleapis/release-please#how-should-i-write-my-commits) |
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.
Could link to Electron's commit message guidelines, which are a lot like Node's (forked docs based on NodeJS's docs), but based around Conventional Commits: https://github.com/electron/electron/blob/master/docs/development/pull-requests.md#commit-message-guidelines
On the other hand, emphasizing fix:
feat:
and BREAKING-CHANGE:
semver hints would help for the release proposal PRs to know whether to bump patch, minor or major. Maybe we should have our own docs page about this?
For dealing with semver manually, release-please-action
can be told to release a specific version, by posting a commit with a Release-As: x.y.z
footer: https://github.com/googleapis/release-please/tree/v11.11.0#how-do-i-change-the-version-number. So maintainers can just do that and not worry very much about individual commit messages, if the need arises.
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.
Maybe link to release-please.yml
.
.github/workflows/release-please.yml
Outdated
{"type":"chore","section":"Miscellaneous","hidden":false}, | ||
{"type":"refactor","section":"Miscellaneous","hidden":false}, | ||
{"type":"ci","section":"Miscellaneous","hidden":false}, | ||
{"type":"travis","section":"Miscellaneous","hidden":false}, |
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.
Travis looks redundant here
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 the feedback.
Travis makes sense to remove, especially since we are only using GitHub Actions now. It's not hurting anything, I think, but it is odd to see it there.
This list is the full set of prefixes that will be included in (read: won't be omitted from) the Changelog.
I expect people won't use most of these, but commit prefixes that release-please
doesn't recognize are left out of the Changelog entirely. I added almost every prefix I saw in the commit history, going all the way back to the first commit to just before the early releases, although I ignored most of the stuff from before NodeJS-style commit metadata were in use. My thinking was "the more the better," for comprehensive coverage. I didn't want anything that is merged to be left out of the Changelog.
On the other hand, leaving certain prefixes out of the list would be a way to intentionally exclude them from the final Changelog. If that would be preferred, (to "reduce clutter" in the Changelog, I suppose?), then I can remove some more of these. (For example: the default for chore:
is exclusion from the Changelog, but now with chore:
on the list, those commits will be included. I thought including them was better.)
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.
Ones I missed or decided not to include:
tools:
(used for some smallgyp
tweaks back in 2018/2019: ea9aff4, e8ea74e, 6f5a408. Two of these patches were ported fromnodejs/node
'stools/gyp
. the original prefix fromnodejs/node
was preserved.)History:
(apparently CHANGELOG.md used to be History.md. 89fe781)addon:
(another smallgyp
tweak: be4ea59)rebuild:
(adjustments to thenode-gyp rebuild
subcommand: 2f675ab, 0eacc90)package:
(Various updates topackage.json
, e.g.: d535620. This doesn't seem like a good prefix to use, in my opinion.)nopt:
(Widening the version range for thenopt
package inpackage.json
... a93752f.)node-gyp:
(Updates to thelib/node-gyp.js
file: e82e438, b4302a3, c4bb689)xcode_emulation:
(A patch cherry-picked from upstreamgyp
that allows running on macOS with "command line tools" rather than full Xcode. The original prefix from upstream was preserved: 5785bae)node_modules:
(pruning unnecessary dirs from the (at that time checked-in)node_modules
dir: 484b286)addon.gypi:
(adjustments to theaddon.gypi
file)remove
(theremove
subcommand ofnode-gyp
(lib/remove.js
): 800179a, 119e030)legacy:
(an oldlegacy
dir, now removed.)jshintrc:
(An old.jshintrc
config file, now removed: b3a147e)windows:
(fully-spelled-outwin:
: 23bd601)list:
(Thelist
subcommand ofnode-gyp
(lib/list.js
): ae4d8d1)core:
(Various updates to the files underlib/
: a185536, ae39e1a, 62e5851, 1354d27)'clean':
(adjustment to theclean
subcommand ofnode-gyp
... quoted for some reason: 06aac83)
Of these, I think I want to add:
- The rest of the subcommands (
clean:
,list:
,rebuild:
,remove:
).- And to complete the
lib/
folder set, maybenode-gyp:
forlib/node-gyp.js
, but I think we should really uselib:
for that instead.
- And to complete the
- Probably add
windows:
, which in turn makes me want to addmac:
andmacOS:
,linux:
and maybelin:
.
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.
Updated.
Although I think maybe encouraging people to just use chore:
fix:
and feat:
might be simpler and for the best. In which case dropping all the custom configured prefixes might be the most appropriate move. (And consider adding a bot that enforces Conventional Commits commit messages? Which might annoy/drive away new contributors... maintainer discipline in what messages are used when landing commits would also take care of the problem without the need for a bot.)
Edit to add: It is possible to lint the commit messages to conform with Conventional Commits with a GitHub Action. I've seen this one used before: https://github.com/marketplace/actions/commit-linter
We don't actually have a Travis CI config file (`.travis.yml`) anymore, and this would be redundant to the "ci" prefix anyway.
More subcommands of node-gyp, and more OSes. Also add documentation comments in the .yml file explaining the categories and order of the prefix entries.
Thanks for dedicated contribution :) |
on: | ||
push: | ||
branches: | ||
- master |
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.
master
or main
?!?
Checklist
npm install && npm test
passesDescription of change
Adds
release-please-action
to this repository.release-please-action
automatically creates/updates release proposal PRs when there are new commits on a given branch of the repository (currently configured asmaster
). If the release proposal PR is merged,release-please-action
will publish a corresponding entry in GitHub Releases, and add the new git tag for that version to the repository.@gengjiawen and I added various NodeJS-style commit prefixes to be recognized in addition to the usual
chore:
,fix:
, andfeat:
prefixes defined in Conventional Commits. (Conventional Commits is the commit message specrelease-please
is based around.) These (and any arbitrary) prefixes are valid per Conventional Commits andrelease-please
, but would be ignored by default -- configuring them as recognized ensures they are not excluded from the generated Changelog.Semver hints in commit messages can let
release-please
know whether to draft a minor or major release; without those, the release proposal PR will be for a semver patch-level release by default.This PR also updates the MarkDown formatting of
CHANGELOG.md
so that older entries will not be overwritten (deleted) in the new release proposal PRs.Finally, this PR updates the "commit guidelines" link in the PR template to point to instructions for
release-please
-style commits, rather than pointing to the NodeJS commit guidelines.Resolves: #2286
Closes: #2330