feat(repo): semver and releasing workflow

[PeterBaker0]

feat(repo): semver and releasing workflow

Description

Follows this guide https://medium.com/valtech-ch/monorepo-semantic-releases-db114811efa5 to implement semantic package versioning in this monorepo. Each package is individually versioned, including automatic tagging and github releasing, based on

a) changes marked with a semantic version commit which include files in that package OR
b) changes to other packages which the package depends on (taking into account package.json installs between packages)

Intended developer workflow

• branch from up to date main e.g. feat-sample-branch or fix-issue-with-loading
• run npm install to ensure package locks are up to date (see note below about this check)
• make changes ensuring commits are signed - no need to use sem versioned commit messages during regular committing
• pull request into main
• TODO: set PR title to semantic version compatible title (this is validated by Semantic PR status check)
• merge PR once reviewed

Benefits

• allow subsequent triggers to be fine grained e.g. on release of API, can publish new docker image
• allow easy referencing of particular points in time in repo
• handle versioning consistently and automatically
• enforce good developer habits by considering scope of changes

Automated steps

• PR title check -> checks on all PRs that the title has a compatible semver format
• package lock up to date check -> checks on all commits on pending PR that the package-lock's are up to date (i.e. npm i has been run) - otherwise the release workflow fails due to pending changes (TODO include this as part of the main release process)
• release on push to main -> when push to main, runs the release-it turbo action, which releases for all packages. This can 1) commit changes 2) push tags 3) make releases.

Squash commits

In order to keep the main history linear and clean, and to only expose release-it to semver compatible commits, I would recommend we

• only allow commits to main through approved PRs
• only allow squash commits/linear history (don't allow merge commits)

TODO before merging

• setup branch protection and squash rules
• setup github OAuth token (and associated service account) to put into releases workflow (this doesn't work with automatic github token, need a personal access token)
• validate trigger conditions (e.g. do we want to not filter on PR merged, maybe just push to main?)

Further work

• setup a top level release config for the whole project which includes all changes