fluxcd / image-automation-controller

GitOps Toolkit controller that patches container image tags in Git
https://fluxcd.io
Apache License 2.0
155 stars 67 forks source link

Image tag marker doesn't work in top-level yaml array #624

Open antonosmond opened 5 months ago

antonosmond commented 5 months ago

I was trying to use the image update automation to update a tag in a generic YAML file in git. I found it doesn't update the image tag in the YAML if the YAML file has a top-level array. A file like this doesn't work i.e. the image automation never updates the tag:

- serviceName: busybox
  containerName: busybox
  tag: 0.0.1 # {"$imagepolicy":"flux-system:busybox:tag"}

But this works:

serviceName: busybox
containerName: busybox
tag: 0.0.1 # {"$imagepolicy":"flux-system:busybox:tag"}

And this also works:

tags:
  - serviceName: busybox
    containerName: busybox
    tag: 0.0.1 # {"$imagepolicy":"flux-system:busybox:tag"}

I'm not sure what versions of flux this applies to but I'm using:

$ flux -v
flux version 2.0.1

And the image automation controller tag is:

image: ghcr.io/fluxcd/image-automation-controller:v0.35.0
stefanprodan commented 5 months ago

Image automation only works for YAML files which start with apiVersion and kind.

antonosmond commented 5 months ago

Hey @stefanprodan

Maybe it's unexpected then but it does actually work for generic YAML files too. In my testing, the entire YAML file I used in a case where it works was:

serviceName: busybox
containerName: busybox
tag: 0.0.1 # {"$imagepolicy":"flux-system:busybox:tag"}

So it's not a k8s resource but works just fine. Feel free to try it. And here's a commit from the image automation in my test repo: https://github.com/antonosmond/flux/commit/6399612d9e1a47742aed70c0a46086041e8d7d58 It's updated the k8s deployment and also updated the generic YAML file.

errordeveloper commented 5 months ago

@antonosmond I think there is an incidental case, perhaps we can say it happens to recognise resources that have an object at root, perhaps apiVersion and kind are inferred or something. I have to say, I find that YAML with an array at the top level is a little unorthodox ;)

antonosmond commented 5 months ago

@antonosmond I think there is an incidental case, perhaps we can say it happens to recognise resources that have an object at root, perhaps apiVersion and kind are inferred or something. I have to say, I find that YAML with an array at the top level is a little unorthodox ;)

I agree. I didn't come up with that format but it's something I can change anyway so gonna change it. Just raised the issue in case it was something that would be expected to work.