Is it possible to exclude some commits from semantic release release notes?

Question

I have a case where I need to include the commit in the semantic-release/commit-analyzer but not in semantic-release/release-notes-generator. Is it possible to do this in Github actions semantic release?

Answer 1

Semantic-release will only (by default) include commits which trigger a release in the release notes. So commits which e.g. begin with ci: or refactor: don't make it through.* I think this is your usecase here---an automated commit which triggers some action but does not in itself constitute a release.

Update it seems you really do want to trigger a version bump without documenting what you did. I think that's a bad idea (expanded below), but it is possible with a hack like this:

Silent Commits

The whole point of semantic-release is that every version-bump-worthy change is documented. However if you really want to produce a hidden bump, you can use a hack along the lines of:

1. save latest tag to a var or file
2. run semantic release without the @semantic-release/github action, but with the @semantic-release/changelog action, writing the changelog somewhere that the git release will not pick it up, i.e. outside the cloned dir.
3. run a custom script which:

• parses your changelog.md
• gets the most recent release notes (easy: parse by headline)
• checks whether you have released, i.e. if the first headline tag is not the tag you got in step 1.
• strips out the 'bad' line
• outputs to stdout (redirect to a var) or writes somewhere

4. iff there is some output, create the github release yourself, using one of the various actions, and set the message to be the output from your script.

Reasons not to do this

I'm just some random guy on the internet, but I don't think this is a good idea. Reasoning:

The whole point about semantic-release is to make releasing 'boring and unromantic': more specifically that every release-worthy commit triggers a documented release. Now either your automated fix: stuff commit does actually fix stuff (in which case this is noteworthy and should be included), or it doesn't, in which case you have some other problem (maybe you are trying to release for 'romantic and interesting' reasons? Maybe you need a release every n days even if nothing has actually changed?). In either case, hiding a legitimate fix is not the way to go about it.

If your problem is a kind of 'microfix' which should generate a release, but happens so frequently as to clog up the release notes, you might want a prerelease branch (where lots of microfixs get rolled up into one big fix in the merge commit).

*assuming you're using conventional commits