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.
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.
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.
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.
Ones I missed or decided not to include:
tools:(used for some smallgyptweaks back in 2018/2019: ea9aff4, e8ea74e, 6f5a408. Two of these patches were ported fromnodejs/node'stools/gyp. the original prefix fromnodejs/nodewas preserved.)History:(apparently CHANGELOG.md used to be History.md. 89fe781)addon:(another smallgyptweak: be4ea59)rebuild:(adjustments to thenode-gyp rebuildsubcommand: 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 thenoptpackage inpackage.json... a93752f.)node-gyp:(Updates to thelib/node-gyp.jsfile: e82e438, b4302a3, c4bb689)xcode_emulation:(A patch cherry-picked from upstreamgypthat 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_modulesdir: 484b286)addon.gypi:(adjustments to theaddon.gypifile)remove(theremovesubcommand ofnode-gyp(lib/remove.js): 800179a, 119e030)legacy:(an oldlegacydir, now removed.)jshintrc:(An old.jshintrcconfig file, now removed: b3a147e)windows:(fully-spelled-outwin:: 23bd601)list:(Thelistsubcommand ofnode-gyp(lib/list.js): ae4d8d1)core:(Various updates to the files underlib/: a185536, ae39e1a, 62e5851, 1354d27)'clean':(adjustment to thecleansubcommand 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.
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 |
Checklist
npm install && npm testpassesDescription of change
Adds
release-please-actionto this repository.release-please-actionautomatically 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-actionwill 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-pleaseis 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-pleaseknow 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.mdso 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