Discussion: decision parameters for creating new revision string
@gsgl and I ran into a broken job https://gitlab.com/gitlab-com/gl-infra/platform/runway/deployments/gsgl-dev-zh2ru5/-/jobs/7121822476 when attempting to deploy without any "meaningful" change that would not trigger a new random_string
resource creation (i.e. keeper object changes).
This would create 2 traffic targets of the same revision name and raises an error
Error: Duplicate object key
│
│ on outputs.tf line 14, in output "traffic_map":
│ 13: for service in google_cloud_run_v2_service.[MASKED]_service : service.location => {
│ 14: for each in service.traffic : each.revision => {
│ 15: traffic_pct = each.percent
│ 16: tag = each.tag
│ 17: }
│ 18: }
│ ├────────────────
│ │ each.revision is "gsgl-dev-zh2ru5-2ea4"
│
│ Two different items produced the key "gsgl-dev-zh2ru5-2ea4" in this 'for'
│ expression. If duplicates are expected, use the ellipsis (...) after the
│ value expression to enable grouping by key.
One immediate use case which would be affected would be bumping runwayctl version on service projects where the docker images are built in a separate project. https://gitlab.com/gitlab-com/gl-infra/cells/topology-service-deployer and https://gitlab.com/gitlab-org/secure/sast-ide-integration are two of such projects.
The longer term discussion would be about how runway should determine if a new revision should be created. As we add more features into the runway.yml
, the keeper object gets larger and there is a maintenance toil of ensuring that new features are tracked in the keeper.
Perhaps there is a way for runwayctl
to produce a single hash for a TF_VAR_keeper_sha
(hypothetical name)? This opens up the avenue for testing and integration with how deploy
reads in information (yml, env, arguments).