CronWorkflow does not get image updated

[8th-block]

trafficstars

Describe the bug

• I use ArgoCD with Argo Image updater.
• Apps that are using CronWorkflow don't get image tags updated in workflows
• Image tags are synced into .argo_*** kustomize file ok though

To Reproduce See below for simplest set up to reproduce

Expected behaviour image tag on in the CronWorkflow should be updated to the latest, i.e. 3.17.5

Additional context n/a

Version Argo CD: v2.7.6+00c914a.dirty Argo Workflow: v3.4.8 Argo image updater: v0.12.2

Logs n/a

01-cronworkflow.yaml

apiVersion: argoproj.io/v1alpha1
kind: CronWorkflow
metadata:
  name: test-cron-wf
  namespace: jobs
spec:
  schedule: "* * * * *"
  concurrencyPolicy: "Replace"
  startingDeadlineSeconds: 0
  workflowSpec:
    entrypoint: whalesay
    templates:
    - name: whalesay
      container:
        # The below never gets updatedby Argo image updater
        image: alpine:3.17.1
        command: [sh, -c]
        args: ["echo 'BAM! I am a whale'; sleep 5"]

kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- 01-cronworkflow.yaml

test-cron-wf-argo-app.yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: test-cron-wf-argo-app-app
  labels:
    job: test-cron-wf-argo-app
  annotations:
    argocd-image-updater.argoproj.io/git-branch: master
    argocd-image-updater.argoproj.io/image-list: 'alpine=alpine:~3.17.1'
    argocd-image-updater.argoproj.io/alpine.force-update: "true"
    argocd-image-updater.argoproj.io/write-back-method: 'git:secret:argocd/[YOUR SECRET]'
spec:
  destination:
    name: ''
    namespace: jobs
    server: 'https://kubernetes.default.svc'
  source:
    path: [PATH/TO/THE/ABOVE/KUSTOMIZE]
    repoURL: 'git@PATH/TO/GIT/REPO'
    targetRevision: master
  sources: []
  project: prod
  syncPolicy:
    automated:
      prune: false
      selfHeal: false
    syncOptions:
      - CreateNamespace=true

Other types such as deployments or KEDA scalers work just fine only Argo's CronWorkflow seems to be an issue here.

Also want to stress that argo image updater does push ".argocd-source-test-cron-wf-argo-app-app.yaml" with the correct version of alpine in this case. The issue is the actual CronWorklow stays at the at 3.17.1

.argocd-source-test-cron-wf-argo-app-app.yaml

kustomize:
  images:
  - alpine:3.17.5

[kodzimo]

We are experiencing something familiar, maybe the same. Once CronJob created with these annotations:

    argocd-image-updater.argoproj.io/image-list: myimage=your-registry.com/service-name
    argocd-image-updater.argoproj.io/myimage.update-strategy: latest
    argocd-image-updater.argoproj.io/myimage.allow-tags: regexp:your-regex

and no Jobs were started with Pods, ArgoCD continues to write logs like these:

time="2023-09-25T12:53:29Z" level=debug msg="Processing application your-application"
time="2023-09-25T12:53:29Z" level=debug msg="Image 'group/service/image' seems not to be live in this application, skipping" application=your-application

But after that the first Job is scheduled and the Pod started with no matter what image tag. If image updater finds that application with working Job with Pod - it will perform the update. But if not - it will continue to write logs, mentioned above. If parameter update is successful, the next scheduled Job will start with updated image.

[Garett-MacGowan]

+1 to this.

If you're using argocd-image-updater with image tags such as latest, dev, staging, etc. + argocd writeback method, then it may be a sufficient workaround to simply use:

  mainContainer: |
    imagePullPolicy: Always

In the workflow controller conifgmap. Of course, the downside is that you don't get to define explicit versions in code. On a rollback, you would have to re-tag an old image or build a new copy of an old image + tag.

[clement94310]

Hello i have a similar problem did someone find a solution ?

[8th-block]

+1 to this.

If you're using argocd-image-updater with image tags such as latest, dev, staging, etc. + argocd writeback method, then it may be a sufficient workaround to simply use:

  mainContainer: |
    imagePullPolicy: Always

In the workflow controller conifgmap. Of course, the downside is that you don't get to define explicit versions in code. On a rollback, you would have to re-tag an old image or build a new copy of an old image + tag.

Yes but it is not recommended. I always run exact versions to avoid surprises