CI/CD Commit/Tag Flow Consolidation

[amydevs]

Specification

A race condition was discovered where the CI/CD pipeline triggered by a Tag may merge bad changes to master.

The CI/CD must be changed so that:

• Tag pipeline now only publishes releases, without guarantee of succeeded tests
• npm version only creates a version commit rather than both a version commit and tag
• Tests and merge jobs should happen on all pipelines on commits on staging, including version commits.
• Tags should be created manually from the version commits after the pipeline of the version commit has succeeded.
• Tags and Releases should only be created from master

This will now mean that, any Tags that's history diverge from staging/master, will no longer be merged into master. This makes sense, as tags can be created from any history, even one that doesn't align with any branches on the repository.

This means that master will only ever be merged from staging, after staging is confirmed to have been successfully tested.

The flow to release should be the following:

1. Commit to staging
2. Run npm config set git-tag-version=false to disable tags from being created from npm version
3. Run npm version ... to create a version commit
4. git push
5. CI/CD runs tests on staging.
6. CI/CD merges staging to master
7. Create a Tag from master
8. CI/CD publishes GitHub release from Tag

Additional context

Tasks

1. Change .gitlab-ci.yml on Polykey to reflect changes
2. Change .gitlab-ci.yml on Polykey-CLI to reflect changes

[CMCDragonkai]

This https://github.com/MatrixAI/Polykey-CLI/issues/40#issuecomment-1907579883 might be relevant here too.

[CMCDragonkai]

@brynblack

[CMCDragonkai]

With the completion of https://github.com/MatrixAI/Orchestrator/issues/10 is this still a problem @brynblack?

[brynblack]

I'm not 100% certain, but generally this is fixed as it is a requirement for a tagged release to pass all checks to get merged into master. So there shouldn't be any cases of bad tagged releases into production.

[CMCDragonkai]

Check with @amydevs to see if this is still a problem...