Remaining work:

• Zoom-out and decide on our dev > release workflow including thinking through individual image releases (i.e. at what points to we publish releases, do we make it automatic from the start or phase into that, do we use Github Releases in addition to our CHANGELOGs, etc)
• Introduce Actions way to manually kick-off a release for an individual product and restore Dockerhub push to work mostly as before
  - [ ] Update "Release checklist" / documentation accordingly
• Merge, and make initial releases!

Includes work detailed in: #733.

Addresses partially or completely all of these Phab tickets:

• T368382: Decision: Repository organisation (monorepo, etc)
• T349803: Automate versioning increment (major, minor, or patch version)
• T352252: Design and implement CHANGELOGs
• T369642: Make the release of individual WBS Images possible
• T364924: Make ARM releases

Implementation summary:

Note: Initial work started in #731 and #733. These PRs can be re-opened, reviewed, and merged before this PR if it is helpful for review.

Uses nx / nx release for managing all the steps of release up until actually pushing things to Docker Hub, including:

• Setting version (stored in package.json in each project)
• Generating CHANGELOG.md entries in each project from commits between previous version and the current

There are several more things we can do here, including integrating this into Github Actions, but this is the starting place which gives us what we need to manually generate a consistent and correct version of a project (either an image or deploy) independently along with an automatically generated CHANGELOG.md entries.

While this uses the "non-Javascript" version of the nx installation to keep the noise down a bit, it does still require node and npm to be installed on the local dev machine. A Docker'ized version of this setup is probably possible, but may be adding a lot of extra friction (or not), TBD. For now I'm focused on getting the configuration correct.

Note: The names of the mixed-case build/* directories have been made all lowercase to match the name of the image that goes up on Dockerhub. Because of how git handles case changes you will need to rm -rf build within the root of the repository before you will be able to successfully check out this branch. The same in reverse...

Adoption:

1. Try it out!: ./nx release --first-release --dry-run and look carefully at the log of the various things that would happen to understand how this all works.

2. Versioning will rely on our tags. Recommended: Removing all your local git tags and re-pull the current set of tags from the Github remote:

git tag -d $(git tag -l)
git fetch

3. Versions are automatically derived according to commits messages. To make sure this works correctly make commit messages using Conventional Commits prefixes (feat:, fix:, and chore:), and optionally but preferably with the product name scope (feat(wikibase):, etc). You could choose to forego this in development as we rely upon squash commits, but it is crucial that the squash commit message uses this format. Breaking Changes need to have "BREAKING CHANGE: ` in the commit footer message. Please read through and get familiar with Conventional Commits here: https://www.conventionalcommits.org/en/v1.0.0. *

4. One engineer carefully make the first pre-release series using this sequence for each project, initially with --dry-run, but remove and go ahead and make the release once you're satisfied with the results:

./nx release version prerelease -p <project-name> --dry-run
./nx release changelog <version-returned-above> -p <project-name> --interactive --first-release --dry-run

For example, to see how the next pre-release of wikibase would be setup:

./nx release version prerelease -p wikibase --first-release --dry-run
./nx release changelog 3.0.1-0 -p wikibase --interactive --first-release --dry-run