GitUpdateAutomation

[paschdan]

It would be really cool, if we could have something like the ImageUpdateAutomation for GitRepositories, and not only for OCI based images.

I could imagine such things:

# GitReleasePolicy
apiVersion: source.toolkit.fluxcd.io/v1alpha1
kind: GitReleasePolicy
metadata:
  name: podinfo
  namespace: flux-system
spec:
  gitRepositoryRef:
    name: podinfo
  policy:
    semver:
      range: 5.0.x

#values.yaml for a helm chart
image:
  registry: ghcr.io
  repository: stefanprodan/podinfo
  tag: 5.0.0 # {"$gitreleasepolicy": "flux-system:podinfo"}

which will then be updated via the ImageUpdateAutomation

[paschdan]

maybe this would also be a nice addition:

# {"$gitreleasepolicy": "flux-system:podinfo:release"} -> 5.2.0
# {"$gitreleasepolicy": "flux-system:podinfo:commit"} -> ef98a040c89180a4f39c0ab01dac47e6c3fced08

[stefanprodan]

@paschdan release is not a Git thing but a GitHub one like Pull Request ;)

The marker extensions could be:

• commit
• tag
• branch

[squaremo]

I don't understand the use case -- I gather from the values.yaml snippet that the tag ends up referring to an image, so why do you need to get it from a git release rather than the image you're going to use?

[stefanprodan]

The use-case I had in mind is running Jobs defined in the bootstrap repo when some other repo changes:

apiVersion: kustomize.toolkit.fluxcd.io/v1beta1
kind: Kustomization
metadata:
  name: apps
spec:
  interval: 5m
  path: "./jobs/some-app-hooks"
  force: true
  postBuild:
    substitute:
      pod_label: "placeholder" # {"$gitpolicy": "flux-system:some-app:commit"}
  healthChecks:
    - apiVersion: batch/v1
      kind: Job
      name: some-app-hook1
      namespace: dev
    - apiVersion: batch/v1
      kind: Job
      name: some-app-hook2
      namespace: dev

[paschdan]

My usecase is, that i have another kustom resource, that can take a tag but is not an OCI image. For example we do have a CRD, that represents a serverless function that can be defined through a git repository reference. The operator for those serverless functions will then create the docker image on the fly.

so in the target git repository we will have tag/releases, but we do not build any container images.