addOutputArtifactsVolumes for wait container not working when main container use subPathExpr

[neteric]

Pre-requisites

• I have double-checked my configuration
• I have tested with the :latest image tag (i.e. quay.io/argoproj/workflow-controller:latest) and can confirm the issue still exists on :latest. If not, I have explained why, in detail, in my description below.
• I have searched existing issues and could not find a match for this bug
• I'd like to contribute the fix myself (see contributing guide)

What happened? What did you expect to happen?

--------------------when-----------------
main container spec:

  - command:
    - /var/run/argo/argoexec
    - emissary
    - --loglevel
    - info
    - --log-format
    - text
    - --gloglevel
    - "0"
    - --
    - bash
    - /usr/local/bin/main.sh
    env:
    - name: WORKFLOW_INSTANCE_NAME
      valueFrom:
        fieldRef:
          apiVersion: v1
          fieldPath: metadata.labels['opsis/instance-identify']
    name: main
    volumeMounts:
    - mountPath: /opsis/workspace
      name: workspace
      subPathExpr: $(WORKFLOW_INSTANCE_NAME)
    workingDir: /opsis/workspace

-----------------------But -----------------------------------------
wait container copy volumeMount from main container, but missing env :

  - command:
    - argoexec
    - wait
    - --loglevel
    - info
    - --log-format
    - text
    - --gloglevel
    - "0"
    env:
    - name: ARGO_POD_NAME
      valueFrom:
        fieldRef:
          apiVersion: v1
          fieldPath: metadata.name
    - name: ARGO_POD_UID
      valueFrom:
        fieldRef:
          apiVersion: v1
          fieldPath: metadata.uid
    - name: ARGO_WORKFLOW_NAME
      value: opsis-user-deploy-1
    - name: ARGO_WORKFLOW_UID
      value: cfcdada3-ec09-4319-acc0-47c9a74bd0d6
    - name: ARGO_CONTAINER_NAME
      value: wait
    - name: ARGO_NODE_ID
      value: opsis-user-deploy-1-1214789585
    - name: ARGO_INCLUDE_SCRIPT_OUTPUT
      value: "false"
    - name: ARGO_DEADLINE
      value: "0001-01-01T00:00:00Z"
    - name: ARGO_PROGRESS_FILE
      value: /var/run/argo/progress
    - name: ARGO_PROGRESS_PATCH_TICK_DURATION
      value: 1m0s
    - name: ARGO_PROGRESS_FILE_TICK_DURATION
      value: 3s
    image: quay.io/argoproj/argoexec:v3.7.2
    imagePullPolicy: IfNotPresent
    name: wait
    volumeMounts:
    - mountPath: /mainctrfs/opsis/workspace
      name: workspace
      subPathExpr: $(WORKFLOW_INSTANCE_NAME)

Version(s)

v3.7.2

Paste a minimal workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflow that uses private images.

null

Logs from the workflow controller

kubectl logs -n argo deploy/workflow-controller | grep ${workflow}

Logs from in your workflow's wait container

kubectl logs -n argo -c wait -l workflows.argoproj.io/workflow=${workflow},workflow.argoproj.io/phase!=Succeeded

[dst03106]

Hi! @neteric
Just sharing my personal thoughts:

Unlike the main container, the init and wait containers aren’t user-defined — they seem intentionally designed not to share the user-defined env variables from the main container.

Just for reference, the wait container uses the env defined in the Executor (ref. code),
so to add new env, you'd need to update the executor's env in the workflow-config-map and redeploy
(though that's probably not a typical use case.)

kubectl -n argo edit configmap workflow-controller-configmap
kubectl -n argo rollout restart deployment/workflow-controller