image-automation-controller: ImageUpdateAutomation creates multiple (incorrect) commits for 1 update

Describe the bug

I have setup an ImageUpdateAutomation to update docker image tags in a git repo containing a bunch of yaml files. The files contain update tags, like this:

imageTag: v5.3.0 # {“$imagepolicy”: “flux-system:backend-production:tag”}

The ImageUpdateAutomation:

spec:
  git:
    checkout:
      ref:
        branch: candidates
    commit:
      author:
        email: bla@...
        name: github-ci
      messageTemplate: '{{range .Updated.Images}}{{println .}}{{end}}'
    push:
      branch: candidates
  interval: 10m0s
  sourceRef:
    kind: GitRepository
    name: config
  update:
    path: ./k8s/flux
    strategy: Setters

The image policy looks as follows:

spec:
  imageRepositoryRef:
    name: backend
  policy:
    semver:
      range: '>v1.0.0'

This all works as expected, except that when an updated image tag is pushed, the image update controller creates a bunch of commits switching back and forth between the current and the new tag, like this:

commit ded9165a3613e4c91afba1227e6892a26d6789a5
Date:   Fri Feb 3 23:31:24 2023 +0000

    eu.gcr.io/company-cloud/company-backend:v5.3.1

diff --git a/k8s/flux/production/shared/helm-backend.yaml b/k8s/flux/production/shared/helm-backend.yaml
index 86239bde..1850e6c5 100644
--- a/k8s/flux/production/shared/helm-backend.yaml
+++ b/k8s/flux/production/shared/helm-backend.yaml
@@ -19,7 +19,7 @@ spec:
     remediation:
       retries: -1
   values:
-    imageTag: v5.3.0 # {"$imagepolicy": "flux-system:backend-production:tag"}
+    imageTag: v5.3.1 # {"$imagepolicy": "flux-system:backend-production:tag"}
   valuesFrom:
   - kind: ConfigMap
     name: helm-values

commit 29aa71f35eb74940ac963f9cbd0e9b5616312250
Date:   Fri Feb 3 23:31:16 2023 +0000

    eu.gcr.io/company-cloud/company-backend:v5.3.0

diff --git a/k8s/flux/production/shared/helm-backend.yaml b/k8s/flux/production/shared/helm-backend.yaml
index 1850e6c5..86239bde 100644
--- a/k8s/flux/production/shared/helm-backend.yaml
+++ b/k8s/flux/production/shared/helm-backend.yaml
@@ -19,7 +19,7 @@ spec:
     remediation:
       retries: -1
   values:
-    imageTag: v5.3.1 # {"$imagepolicy": "flux-system:backend-production:tag"}
+    imageTag: v5.3.0 # {"$imagepolicy": "flux-system:backend-production:tag"}
   valuesFrom:
   - kind: ConfigMap
     name: helm-values

commit 8fc27bdef09cda5339fa349f8b76cb037bcf7d35
Date:   Fri Feb 3 23:31:07 2023 +0000

    eu.gcr.io/company-cloud/company-backend:v5.3.1

diff --git a/k8s/flux/production/shared/helm-backend.yaml b/k8s/flux/production/shared/helm-backend.yaml
index 86239bde..1850e6c5 100644
--- a/k8s/flux/production/shared/helm-backend.yaml
+++ b/k8s/flux/production/shared/helm-backend.yaml
@@ -19,7 +19,7 @@ spec:
     remediation:
       retries: -1
   values:
-    imageTag: v5.3.0 # {"$imagepolicy": "flux-system:backend-production:tag"}
+    imageTag: v5.3.1 # {"$imagepolicy": "flux-system:backend-production:tag"}
   valuesFrom:
   - kind: ConfigMap
     name: helm-values

So in this case the new tag was v5.3.1, which was updated in the first commit, but then there’s a second commit with v5.3.0 (previous version), and then another v5.3.1 commit. I would expect there to be just 1 commit with the new version tag.

Steps to reproduce

  1. Set up an image repository
  2. Create an ImageUpdateAutomation and ImagePolicy as specified above
  3. Push a new image to the repo with a new tag
  4. Multiple commits created instead of 1

Expected behavior

I would expect only 1 commit with the new version.

Screenshots and recordings

No response

OS / Distro

N/A

Flux version

flux: v0.36.0

Flux check

► checking prerequisites ✗ flux 0.36.0 <0.39.0 (new version is available, please upgrade) ✔ Kubernetes 1.24.8-gke.2000 >=1.20.6-0 ► checking controllers ✔ helm-controller: deployment ready ► ghcr.io/fluxcd/helm-controller:v0.26.0 ✔ image-automation-controller: deployment ready ► ghcr.io/fluxcd/image-automation-controller:v0.26.1 ✔ image-reflector-controller: deployment ready ► ghcr.io/fluxcd/image-reflector-controller:v0.22.1 ✔ kustomize-controller: deployment ready ► ghcr.io/fluxcd/kustomize-controller:v0.30.0 ✔ notification-controller: deployment ready ► ghcr.io/fluxcd/notification-controller:v0.28.0 ✔ source-controller: deployment ready ► ghcr.io/fluxcd/source-controller:v0.31.0 ► checking crds ✔ alerts.notification.toolkit.fluxcd.io/v1beta1 ✔ buckets.source.toolkit.fluxcd.io/v1beta1 ✔ gitrepositories.source.toolkit.fluxcd.io/v1beta1 ✔ helmcharts.source.toolkit.fluxcd.io/v1beta1 ✔ helmreleases.helm.toolkit.fluxcd.io/v2beta1 ✔ helmrepositories.source.toolkit.fluxcd.io/v1beta1 ✔ imagepolicies.image.toolkit.fluxcd.io/v1beta1 ✔ imagerepositories.image.toolkit.fluxcd.io/v1beta1 ✔ imageupdateautomations.image.toolkit.fluxcd.io/v1beta1 ✔ kustomizations.kustomize.toolkit.fluxcd.io/v1beta2 ✔ ocirepositories.source.toolkit.fluxcd.io/v1beta2 ✔ providers.notification.toolkit.fluxcd.io/v1beta1 ✔ receivers.notification.toolkit.fluxcd.io/v1beta1 ✔ all checks passed

Git provider

GitHub

Container Registry provider

Google Container Registry (GCR)

Additional context

No response

Code of Conduct

  • I agree to follow this project’s Code of Conduct

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 27 (12 by maintainers)

Most upvoted comments

I think you need to use GCR and push new images in a loop.