when using the emissary executor you must either explicitly specify the command,

[nishit93-hub]

Hi,
I am getting the below error after submitting the build-container-image.yaml workflow.

task 'toolkit-f84wm.build-container-image' errored: when using the emissary executor you must either explicitly specify the command, or list the image's command in the index: https://argoproj.github.io/argo-workflows/workflow-executors/#emissary-emissary

[vfarcic]

I haven't been using the emissary executor (just yet) and, unfortunately, I do not have access to my work computer (on mini hollidays...).

From what I saw, the solution is to add command: [/kaniko/executor] to the template. Can you do me a favor and try it out?

[nishit93-hub]

Hi, I tried the command you mentioned above.

This is my workflow.

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: build-container-image-
  labels:
    workflows.argoproj.io/archive-strategy: "false"
spec:
  entrypoint: build
#  serviceAccountName: workflow
  volumes:
  - name: kaniko-secret
    secret:
      secretName: regcred
      items:
        - key: .dockerconfigjson
          path: config.json
  templates:
    - name: build
      metadata:
#      inputs:
#      parameters:
#      - name: app_repo
#      - name: container_image
#      - name: container_tag      
        artifacts:
          - name: source
            path: .
            git:
              repo: https://xxxxxxxxxxxxxxxxxxxxxx/xxx.git          
      container:
        image: gcr.io/kaniko-project/executor:latest
        command: [/kaniko/executor]
        args: ["--context= https://xxxxxxxxxxxxxxxxxxxxxx/xxx.git","--destination=moustakis/kaniko-build-demo:1.0.0"]
        volumeMounts:
          - name: kaniko-secret
            mountPath: /kaniko/.docker/ 

Now, this is what is said.

INFO[0000] Retrieving https tar file
INFO[0001] Retrieved https tar file
Error: error resolving source context: gzip: invalid header
Usage:
  executor [flags]
  executor [command]

Available Commands:
  help        Help about any command
  version     Print the version number of kaniko

I even used that command in your ClusterWorkflowTemplate (container-image.yaml) file. However still showing emissary executor error.

[vfarcic]

I'll. be back right after New Year's eve and will go through it. I hope that's not too late for you.

[nishit93-hub]

Ok, No problem. However, the issue has been resolved by using command: [/kaniko/executor].

One thing I want to ask, how can I automatically assign docker-image tags. Below is my code.

   container:
      image: gcr.io/kaniko-project/executor:latest
      command: [/kaniko/executor]
      args:
        - "--context=dir:///workspace"
        - "--destination=nishit2408/argo-imageupdater:4.0"

I want Argo workflow should assign new tag names automatically every time I re-submit the workflow.

[vfarcic]

Normally, you would calculate the new tag, put it in an environment variable, and use it when constructing the arguments. The calculation itself can be random, or Git commit hash, or the Git tag (if you're creating tags), or semantic versioning (my favorite), or any other logic. I prefer semantic versioning and, in those cases, you would either extract it from the commit messages (if you do add the desired tag there) or generate it using one of many binaries that do that. Unfortunately, I'm not in front of a working computer to check out what I'm using to generate semantic versions (it's one of those things that you do once or twice and forget about it). If you Google something like "semantic version generator" you should be able to find it quickly.

[nishit93-hub]

@vfarcic Hi, I am using {{workflow. name}} as a workflow variable, which is assing a new docker image tag. However, Argo image updater couldn't update this tag.

Using the below annotation.

  annotations:
    argocd-image-updater.argoproj.io/image-list: nishit2408/argo-imageupdater:*

[vfarcic]

It's hard to say what's wrong based only on that info.

Can you post the whole manifest, especially the rest of the annotations? Also, please post the logs from the image updater.

[nishit93-hub]

@vfarcic Here is the manifest

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: gitops-image-updater
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
  annotations:
    argocd-image-updater.argoproj.io/image-list: nishit2408/argo-imageupdater:*
    argocd-image-updater.argoproj.io/write-back-method: git:secret:argocd/repo-322047772
    argocd-image-updater.argoproj.io/git-branch: master
spec:
  project: default
  source:
    repoURL: ssh://[email protected]:/home/git/repos/wordpress-manifest
    targetRevision: master
    path: kustomization/development
  destination:
    server: https://kubernetes.default.svc
    namespace: imageupdate-dev
  syncPolicy:
    syncOptions:
      - CreateNamespace=true
    automated:
      selfHeal: true
      prune: true
      allowEmpty: true

And here are the logs

time="2022-01-23T18:50:52Z" level=info msg="Successfully updated the live application spec" application=gitops-image-updater
time="2022-01-23T18:50:52Z" level=info msg="Processing results: applications=1 images_considered=1 images_skipped=0 images_updated=1 errors=0"
time="2022-01-23T18:52:52Z" level=info msg="Starting image update cycle, considering 1 annotated application(s) for update"
time="2022-01-23T18:52:53Z" level=info msg="Processing results: applications=1 images_considered=1 images_skipped=0 images_updated=0 errors=0"
time="2022-01-23T18:54:53Z" level=info msg="Starting image update cycle, considering 1 annotated application(s) for update"
time="2022-01-23T18:54:54Z" level=info msg="Processing results: applications=1 images_considered=1 images_skipped=0 images_updated=0 errors=0"
time="2022-01-23T18:56:54Z" level=info msg="Starting image update cycle, considering 1 annotated application(s) for update"
time="2022-01-23T18:56:55Z" level=info msg="Processing results: applications=1 images_considered=1 images_skipped=0 images_updated=0 errors=0"
time="2022-01-23T18:58:55Z" level=info msg="Starting image update cycle, considering 1 annotated application(s) for update"
time="2022-01-23T18:58:56Z" level=info msg="Processing results: applications=1 images_considered=1 images_skipped=0 images_updated=0 errors=0"
time="2022-01-23T19:00:56Z" level=info msg="Starting image update cycle, considering 1 annotated application(s) for update"
time="2022-01-23T19:00:57Z" level=info msg="Processing results: applications=1 images_considered=1 images_skipped=0 images_updated=0 errors=0"
time="2022-01-23T19:02:57Z" level=info msg="Starting image update cycle, considering 1 annotated application(s) for update"
time="2022-01-23T19:02:58Z" level=info msg="Processing results: applications=1 images_considered=1 images_skipped=0 images_updated=0 errors=0"
time="2022-01-23T19:04:58Z" level=info msg="Starting image update cycle, considering 1 annotated application(s) for update"
time="2022-01-23T19:04:59Z" level=info msg="Processing results: applications=1 images_considered=1 images_skipped=0 images_updated=0 errors=0"
time="2022-01-23T19:06:59Z" level=info msg="Starting image update cycle, considering 1 annotated application(s) for update"
time="2022-01-23T19:07:00Z" level=info msg="Processing results: applications=1 images_considered=1 images_skipped=0 images_updated=0 errors=0"
time="2022-01-23T19:09:00Z" level=info msg="Starting image update cycle, considering 1 annotated application(s) for update"

However, if update the docker image tag manually i.e. 1.0 range then the Argo image updater is able to update that tag.

[vfarcic]

Assuming that Workflows did push your images to the registry, the issue is unrelated to it. Image Updater does not care how are images pushed to the registry.

You are probably missing update-strategy label. By default, Image Updater assumes that you're using semver. If that's not the case, you need to change the update strategy. You can find more info at https://argocd-image-updater.readthedocs.io/en/stable/install/strategies/.