Closed adelton closed 5 months ago
Sorry, I missed this pull request until now.
Looks good to me. @grdryn are we OK with using the first imagetag reference as a registry used for the gitops-update-pipeline? In theory a user can specify different imagetag references, each pointing to a different registry. But gitops-update-pipeline works only with one image as a source. Even if we supported pushing to more than one registry (not just different tags within same registry) we could take the first one as a convention. Wdyt?
For now, yes, if this gets this pipeline from a non-working state to a working state, then it sounds great to me.
We have future work coming as part of RHOAIENG-3128, which aims to make some things more flexible. I think it could be considered within scope of that (and if not that, then a future issue), to just update a digest in the GitOps repo, and let the user have different registry/repo parts for potentially different environments. It would be up to them to ensure that they had specified all of those registries (or the required ones, if they've got some other automated replication) in the target-image-tag-references
parameter of the aiedge-e2e pipeline.
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: adelton, MarianMacik
The full list of commands accepted by this bot can be found here.
The pull request process is described here
Yeah, this PR is just to get the repo working end-to-end again.
Some random thoughts about what we might want to do in the future:
If the GitOps machinery can be given a list of registries to try out, or even somehow process a list of registries and use the most appropriate registry out of that list for each edge location, then we could process and update multiple registries.
Hmm. Or maybe, from a completely different angle, the build pipeline should have no business updating the registry URL, just the SHA, because the fact that it pushed to some registry after build does not mean that that's the registry the edge location should be consuming the new image.
Description
Make the GitOps pipeline find the target registry URL again. This amends e3e731b7bc143e1bbaa3a8f3a5a58bf242631c38 and e1cfc6839c7ec44bd5f5e7e54c31cc8cd22276c5 and uses the
target-image-tag-references
to figure out the registry URL.Also updating the
useMergedBuildTestPipeline
because that's what the repo seems to default to these days.How Has This Been Tested?
Manually.
Merge criteria: