-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Templated mutex name not resolved #13629
Open
2 of 4 tasks
Labels
Comments
Can't reproduce with v3.5.8 and latest |
i got what you mean, UI shows that mutex is not replaced correctly mutex function is actually available, but it is not replaced in the UI. |
Just to precise that when the mutex is named after a workflow parameter which is static, the UI shows the correct name. The issue is about the "double" resolution of the name. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Pre-requisites
: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.What happened? What did you expect to happen?
The mutex name is not resolved correctly when it is based on a workflow parameter, which is also based on another workflow parameter.
See the workflow below.
{{ workflow.parameters.derived-mutex-name }}
derived-mutex-name
is defined as"{{ workflow.parameters.base-mutex-name }}"
base-mutex-name
is defined as a parameter of the argo submit command line, let's saymycustommutex
In this workflow dag is used (and might be the reason of the defect).
With this workflow, if I run the following command:
I get the following message indicating the name of the mutex at runtime:
However the command
echo {{ workflow.parameters.derived-mutex-name }}
outputs correctly the resolved name:I have not tested this scenario with the latest version, because I'm not responsible of the deployment of argo in my company.
Version(s)
v3.5.8
Paste a minimal workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflows that uses private images.
Logs from the workflow controller
Logs from in your workflow's wait container
The text was updated successfully, but these errors were encountered: