Feature 77: Improve Development Actions

[daniel-va]

This feature has not been fully tested and should not be merged yet!

PR for #77.

• Replacement of the ci, dev-deploy and pre-release workflows with the unified build workflow.
• Rewrite of the release workflow.
• The codeql workflow is left as is.

The new build workflow defines the following automatic release process:

1. When pushing to any branch, the code is tested, linted and type checked.
2. If all these actions passed, when pushing to develop, the edge Docker images are built and pushed.
3. If all these actions passed, when pushing to main, the edge Docker images are tagged as release-candidate.

The rewritten release workflow defines the following manual release process:

1. The release-candidate Docker images are tagged as latest.

These workflows contain the following notable changes to their predecessors:

• Builds and releases are only triggered after successful code checks.
• The Docker images are only built once instead of being rebuilt for every sub-release. This is done by adding a new tag to existing images when releasing them.
• The Docker image release for prod is now tagged latest instead of release.
• Docker images are only tagged with actual version numbers when releasing for prod.

[daniel-va]

One point that I'm not yet decided on is how to handle/generate version numbers. The current live workflows use a three-part versioning system (i.e. X.X.X), generated using the following method:

• The first two numbers are taken from the VERSION file. They haven't been changed since their introduction.
• The last number is taken from the run counter of any workflow that is building and tagging Docker images.
• Due to how the current build process works, Docker images are built by three different workflows. This means that we use three different version numbers, one for dev (edge, eX.X.X), one for int (release-candidate, rcX.X.X) and prod (release, vX.X.X). These numbers don't have any direct relation to each other.

The issue with different versions by release would be fixed in this PR, by only building the images once and then just adding new tags per release. However, since the PR replaces the existing workflows, it effectively "resets" the version's last number to 1.

Personally, I would move to a two-part versioning system (i.e. X.X), where the first number is always 1, which should only change if the application is ever fully rewritten or replaced. The second number should be an incrementing number starting at 1. If possible, I would only increment the second number on a prod release, instead of on each dev build, as it happens with the current system. This has the following advantages:

• The version number is fully defined and has meaning.
• Images that are never pushed to prod are automatically replaced instead of being kept forever, as is the case now.
• All pushed images that are tagged with a version number can be assumed to be production ready.