[GKE] Generate a semantic "chart version" when deploying.

For Cloud Run based services, new deployments are triggered by branch pipelines, typically merges into the main branch. The container image is identified by the commit hash, specifically $CI_COMMIT_SHORT_SHA.

Helm requires us to generate a "chart version", which has to use semantic versioning. The application's (semantic) version is only available after the semantic release job has finished.

The intuitive approach was to run deployments from the tag pipeline, i.e. when the v1.2.3 style tags are pushed. This is problematic, however, since these tags are created semantic release using a "project access token". Because the tag pipeline is triggered by a project access token, it is unable to trigger pipelines on the deployment project.

Ideas for work-arounds:

• ❌ Don't increase the chart version when deploying a new application image. Helm recommends to decouple the "chart version" from the "application version". However, Helm charts are stored in a repository using the "chart version", meaning that if we released multiple application versions using the same chart version, only the last application version would be available from the repo. This makes rollbacks impossible.
  • ⇒ we need a new "chart version" for each deployment
• 🤔 In the branch pipeline, block on the "semantic release" job and determine the version from the Git label after is has completed. Note that we only need the tag created by the "semantic release" job; we do not need to wait for the tag pipeline to complete.
• Find a way to run from tag pipelines. Arguably tag pipelines are the best place from which to run a deployment. The main problem is that "project access tokens" cannot be granted access to resources in other projects.

  • ❌ Adding a group or project to the job token allowlist will likely not work either:

    Adding a project to the allowlist does not give additional permissions to the members of the allowlisted project. They must already have permissions to access the resources in your project to be able to use a job token from the allowlisted project to access your project.

  • 👎 Trigger tokens impersonate the account creating them. We'd either use a seat for each Runway-managed service (expensive and probably hard to automate) or grant access to a shared account to all service repos (terrible security posture).

  • 👎 Require deployments to be triggered manually → not desireable