Open mp-az opened 1 year ago
If we introduce a new initial step into our workflow that simply suspends the workflow for 1s then the variables in the next step(s) all work as expected.
- - name: delay
template: delay
...
...
...
- name: delay
suspend:
duration: "1"
This suggest a concurrency / timing issue perhaps ? Are there any known issues with variable values been made available for use in the workflow containers?
I have also tried 3.2.11 and 3.3.10 which demonstrate the same behaviour using both the docker and the emissary runtimes.
At the moment only 3.1.0 works (with both runtimes).
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
maybe related to https://github.com/argoproj/argo-workflows/issues/13799
Pre-requisites
:latest
What happened/what you expected to happen?
When using Global Workflow variables in our Workflows the value of the variable is not interrupted by the first step of the Workflow. Instead the literal string from the Workflow template is returned. Subsequent steps in the workflow work ok and the value is returned in the step output as expected.
We have been running 3.1.0 for a long time and recently upgraded to 3.4.8 which is where we started to see the issue.
In our Workflow we define argument parameters as follows:
When the 'workdir' parameters are is used in Workflow steps we would expect the output to be /mnt/data/model-foo-bar/2023.06.13-0949. The timestamp portion built up in the timestamp parameter and then used in the workdir parameter
When used in the first step we get the following output when we use the workdir variable : /mnt/data/model-foo-bar/{{workflow.creationTimestamp.Y}}.{{workflow.creationTimestamp.m}}.{{workflow.creationTimestamp.d}}-{{workflow.creationTimestamp.H}}{{workflow.creationTimestamp.M}}`}}
In the next step and all subsequent steps the variable value is correctly returned as : {{
/mnt/data/model-foo-bar/2023.06.13-0949
}}We have tried other built-in variables including workspace.namepsace and workspace.uid and experienced the same behaviour.
as mentioned this works Ok in 3.1.0 but we are can't get it to work in 3.4.8. It might be something in our wider configuration but we'd be grateful if you could help investigate the behaviour we are seeing.
Version
3.4.8
Paste a small 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