Introduce Semantic Release for automated code releases

[dhensby]

Hi team.

I've been using semantic release for a while in some of my projects to automate the release process and I think it would be of value to add it to this project too.

Their docs go through the advantages of this approach, but I'll highlight a few that I think are important (as well as some potential drawbacks).

Advantages

1. Release process is defined in code (thus easily done)
2. No reliance on individuals to find time to make releases and no single point of failure for releases
3. Much less error prone (no room for human error when making a release)
4. We can use GitHub actions to perform package attestation (provenance) - this can't be done on local machines and has to be in CI
5. Quickly release features/fixes when merged
6. Automate tedious and easily missed elements like changelog generation

Disadvantages

1. Requires we adopt commit conventions so that the CI process can determine when to make a release and what kind of release to make (typically conventional commits is used) - this may be a good thing depending on your point of view
2. Can lead to large number of releases
3. Reviewers and contributors need to be aware that only working code can go into master and that their commit messages must be accurate.

I'm pretty familiar with the process, so happy to put the work in to integrate it. I will need someone to add some secrets to the GH repo to allow publishing to NPM (I don't need to know the secret, it just needs to be available to the runner when publishing), and we need to come to an agreement about what the release process should include. For example, if we want to include changelog generation, then the CI pipeline will need permission to push to master (or any other release branch).

[jankapunkt]

@dhensby it would be awesome to automate this! What would be needed from my end to prepare for this? Any keys, permissions etc.?

[dhensby]

I don't personally need any permissions. But a github action secrets will need to be created.

• NPM_TOKEN - This must be a granular access token with read-write access to only this package
• GITHUB_TOKEN (optional) - This must be a fine grained access token that can push to branches (circumvent branch protections), this is so updates to package.json and CHANGELOG.md can be pushed as part of a release.

I can author the workflow

[dhensby]

Finally got around to this and it's now available in PR #335