ci: semantic releases

[dhensby]

Summary

This change adds semantic releases to the release pipeline. Commits are automatically analysed when they are merged into master and depending on the commit message (fix, feat), a new release will be authored (tagged in git, pushed to GH releases and NPM); this includes updating the release version in package.json and updating the CHANGELOG.MD.

Other added benefits are NPM attestation of releases, no human dependencies on releases, fixes are released as soon as they are merged.

Contributors will now have to ensure their commits conform to the conventional commits standard

Outstanding actions:

1. Someone with publish permissions to the NPM repository will need to create a fine-grained access token to allow publishing of the package - this must then be added to the github repo secrets with the name NPM_TOKEN.
2. Someone with admin rights to the GH repo will need to create a fine-grained access token to allow pushing to the repository - this must then be added to the github repo secrets with the name GITHUB_TOKEN.

The GH token needs the following access:

      contents: write # to be able to publish a GitHub release & commit changelog changes
      issues: write # to be able to comment on released issues
      pull-requests: write # to be able to comment on released pull requests
      id-token: write # to enable use of OIDC for npm provenance

Linked issue(s)

See discussion #310

Involved parts of the project

Releases / automation.

Added tests?

N/A

OAuth2 standard

N/A

Reproduction

N/A

[jankapunkt]

Thanks a lot for this @dhensby

I have nom publishing access but I'd like to limit this only to the master branch so new releases are definitely reviewed beforehand by at least two of us. What do you think?

[dhensby]

By default the release process won't work unless it's in a list of the default branches (master, next, and then N.x for changes to other versions). We can limit this to just master either in the release config or in the GH workflow (or both).

[jankapunkt]

Ok then we can leverage npm tags so everything on next is also tagged @next (like alpha beta release candidate) and not auto installed by users while releases on master can be tagged @latest so they are installable without explicit version pinning

[dhensby]

Yep - that's how it works "out of the box" 👍