-
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
Template parameter workflow.creationTimestamp
is incorrect when a workflow is retried
#11488
Comments
I just tried to see if I could perhaps use |
I think that's expected since the workflow was created previously. It never got deleted. The behavior you are expecting is for resubmitted workflows. |
@terrytangyuan I think there is a misunderstanding here. To make it clear, when retrying (not resubmitting) a workflow: My expectation is: that the My observation is: the |
@Gerrit-K your expectation is correct it should not change for |
@Gerrit-K Thanks for the clarification! |
@Gerrit-K I can see the code is using
|
@terrytangyuan @sarabala1979 Thanks for getting back to this so quickly! I'm not averse to contributing. However, right now I only had the capacity to report, but not to further investigate. I'll try to find some time to get back to this, setup a dev environment and investigate during the next days/weeks. But if someone, who already has everything set up, is able to quickly test this, I would definitely appreciate it! 🙏 |
I found a bit of time today to look into this. It appears that this is a combination of issues with argo-workflows and the In argo-workflows, the variable When this is evaluated in In my particular case, there are two rather easy workarounds:
IMO, |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
Thanks for digging into this @Gerrit-K !
That is a bit confusing, no doubt, but since it does have subkeys I suppose that kind of makes sense. They are mentioned in the variables page too.
Thanks for the consideration. This would a breaking change to modify, so I think we should leave it as is, at least for now. Your workaround makes sense and it's not a common issue that I've seen, so changing it may create more confusion. Will close this out for now as such.
Yea sprig's default behavior is definitely a bit confusing. Enough so that there is an explicit warning about sprig's error handling in the Argo docs: https://argoproj.github.io/argo-workflows/variables/#expression. See also #11608 where |
Pre-requisites
:latest
What happened/what you expected to happen?
When using
workflow.creationTimestamp
inside a template, I would expect it to match themetadata.creationTimestamp
field of theargoproj.io/v1alpha1.Workflow
object. This is the case for the first run, but if the workflow fails and is retried, the template variable is updated with the current datetime, while the kubernetes metadata field still shows the old timestamp.To reproduce:
Version
latest (v3.4.9)
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
The text was updated successfully, but these errors were encountered: