Allow setting "automated" on Functions

[jpds]

I'm using OpenFaaS in conjunction with Flux, as part of our CI, we build a new tag for the docker image for our functions (to keep it consist with every other pipeline we have).

Setting flux.weave.works/automated: "true" doesn't work for functions, which means that our developers have to tell us when they've pushed a new git commit, unlike our Helm deployed applications everything just works with the same ECR registry.

[2opremio]

@jpds I don't think we have OpenFaaS-support as a priority, however, we are always open to PRs.

[ismailbaskin]

What do you think about a new annotation key to address the CRD's image path?
fluxcd.io/image-path: spec.image for OpenFaas,
fluxcd.io/image-path: spec.template.spec.containers[].image for Knative Service.

The value of the annotation may also have multiple comma-separated paths like fluxcd.io/image-path: spec.image1,spec.image2

[ismailbaskin]

Another alternative can be using a deployment-wide map configuration for CRD GroupVersionKind to its image path.

crds:
 - group: openfaas.com
   version: v1
   kind: Function
   imagePaths:
    - spec.image
 - group: example.com
   version: v1beta1
   kind: MyCustomCRD
   imagePaths:
    - spec.firstImage
    - spec.secondImage

[robinbraemer]

We also need this to work with CRDs! We are using Agones for instance and we
need the image to auto update for the GameServer in a Fleet.

Kustomize can already replace the image in CRs when generating yamls, so Flux should simply consider all resources with the fluxcd.io/automated: "true" annotation to trigger a release!

[antonioberben]

I am creating an operator which allows a CRD with one of the values being the the image tag which latelly will be deployed.

apiVersion: example.com/v1beta1
kind: MyOperator
metadata:
  name: my-operator
  namespace: 'example'
spec: 
      repository: xxx
      tag: v1.0.0

It would be very helpful that thorugh annotations like described above, the value of tag is updated by flux.

Like described by @ismailbaskin :

apiVersion: example.com/v1beta1
kind: MyOperator
metadata:
  name: my-operator
  namespace: 'example'
  annotations:
   fluxcd.io/image-path: spec.tag
   fluxcd.io/automated: "true"
spec: 
      repository: xxx
      tag: v1.0.0

[kingdonb]

This feature is a key development of Flux v2:

https://toolkit.fluxcd.io/guides/image-update/#configure-image-update-for-custom-resources

Besides Kubernetes native kinds (Deployment, StatefulSet, DaemonSet, CronJob), Flux can be used to patch image tags in any Kubernetes custom resource stored in Git.

The image policy marker format is:
{"$imagepolicy": "<policy-namespace>:<policy-name>"}
{"$imagepolicy": "<policy-namespace>:<policy-name>:tag"}

Examples provided include HelmRelease, Tekton Task, Flux Kustomization, and in the Kustomize config (kustomization.yaml), but the documentation states this can be used with any custom resource in Flux v2.

We are excited to offer this heavily requested feature and hope you will all be able to upgrade with us to Flux v2. The 0.8 release which was just announced includes production readiness and 100% feature parity, so it is recommended for anyone who is able to upgrade now to begin migrating their workloads.

Flux v1 is in maintenance mode and won't be receiving new features, we hope everyone can migrate and we are interested in hearing user reports. If there are issues that block your migration, please follow the support guide and read our docs, or open a discussion if needed. Or, meet us on slack, to get access to our community's best-effort support: https://fluxcd.io/support/

Closing since this feature is now available in Flux v2.