Issues with service account used for revamp_dev.yaml

[Alexander-Stuckey]

There are a few issues with the service account(s) used in revamp_dev.yaml.

1. The workload_identity_provider and service_account are defined in three places, for three jobs. However, only the first instance (lines 52 and 53) are stored in secrets manager. The other two instances (85 & 86, 122 & 123) are hardcoded into the file.

2. The service account used for deploy_image_auto and deploy_image_manual do not have permissions to read from images (main), which is is a problem when you want to use an image stored there as the base for your Dockerfile.

3. The deploy_image_auto and deploy_image_manual service account does not have permissions to deploy the image into the dev images artifactory.

[nevoodoo]

@Alexander-Stuckey I'll post my comments below:

1. The reason for this is, the first instance is a new service account, and thus we can hide it in the secrets. The other two instances are used and visible in so many other locations such as the commit history, putting them in the secrets doesn't make sense at this stage and would be redundant. The plan is to create new service accounts at some stage, and then put them in the secrets too.
2. I'm not sure this is accurate, do you have a failed run I can look at for debugging this?
3. This isn't an issue within the images repo but looking at the dragen_align_pa repo, lines 87,88 should use the existing service account and not the one from the secrets - that one is exclusively for reading tags, and is not intended to have permissions to get an image/push an image. I thought it was a permissions issue but I had not looked at the workflow definition more closely when we spoke last week.