After the `docker login` removal in the commit 3327bc most of those scripts are error-prone since they only work when the local has an active session with the quay.io registry. In some other cases, the installation of the operator fails due to missing credentials in the secret pull-secret to access and pull the IIB bundle image.
To see an example of how the flow works in the current scripts:
1. They export the current pull-secret config from the OCP cluster to a file named "authfile":
2. Then, back up the docker config and use "authfile" as it:
3. At this point, they log in with a shared account to append the login information to the JSON file (link here):
4. Move back the docker config files:
5. Now the "authfile", with all the OCP pull-secrets information along with the pull-secret for our personal Quay registry (where the IIB image was pushed), is used to update the proper secret in the cluster:
They are some drawbacks in using this strategy to share the IIB bundle with the cluster:
- We are mirroring the same image several times to individual accounts, and that leaves in the hands of each team member the management of credentials and permissions, apart from the over usage of the platform.
- Using a Quay shared account like devtools allows us to segment the solution into two pieces: The one which pushes the IIB images to the registry, and the other that configures the OCP cluster secret to access those images.
- Moreover, the use of that shared account would simplify the maintenance and cleanup tasks, as well as permit the centralization of those tasks.
We may enhance the gitops-components-automated-testing scripts to find a better solution for retrieving and pushing the IIB images
- To remove and clean up all unnecessary code inside the gcat scripts.
- Store all IIB in a centralize Quay registry.
- Find a way to handle the credentials for Brew Registry instead of prompting for the password (docker login) in every execution.