ImageUpdateAutomationSpec vs. oci://[repo]/kustomization/apps/dev

[gladiatr72]

I have a coworker who is an image-automation enthusiast. I am not at all a fan of giving a cluster service write-access to the repository that is its source of truth. With new installations, I have been gradually adapting my flux patterns to using ECR/GAR/OCI for artifact storage.

The use-case is simple: ImageUpdateAutomation requires write access to the source. The flux/source artifact can remain in git behind its r/o token. We would then drop a script in the flux repo to codify the flux push for apps/app/. The flux/kustomization for the target component supports OCIRepository as a source, so the target kustomization will render. Isolation of image-automation target complete!

I got out ahead of myself a bit--started out with getting the source-controller setup with its IAM bits. I guess I haven't looked directly at the imageupdateautomations spec in a while. I have apparently been moving around the one I configured after the last api change without giving it a lot of thought.

After I got the IAM bits sorted out, my practical objections to the image-automation pattern were mostly gone, but then.. imageupdateautomation.spec.sourceRef.kind <- OCIRepository 💥 roundHole/squarePeg exception

I'm happy to be redirected to any existing discussion or issue. I checked flux2 and imageupdateautomation issues and didn't find anything related (closed or opened).

-S

[matheuscscp]

ImageUpdateAutomation can only write to Git

[stefanprodan]

Flux Operator offers an alternative to image automation that works for OCI artifacts: https://fluxcd.control-plane.io/operator/resourcesets/image-automation/