argoproj / argoproj/argo-workflows
Allow workflowTemplateRef property to work properly when called from a WorkflowTemplate
- Dominant language
- Go
- Stars
- 17k
- Forks
- 3.7k
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 138
Description
# Summary
Currently when workflowTemplateRef property is used to reference a workflow template from another workflow template, it does not work properly. There seems to be an error when trying to resolve the entrypoint.
It would be nice to allow this feature as then we can have saved WorkflowTemplates with different argument sets that call the underlying base WorkflowTemplate which we don't need to duplicate.
There is an issue which has already outline this problem in the past but nothing happened with it #5665
# Use Cases
When you have a bunch of jobs that use the same WorkflowTemplate but have different argument sets. For example I have a load of services that I want to be able to build and deploy through the Argo Workflow UI at the click of button, they all use the same WorkflowTemplate but have different arguments/parameters. I want to have a saved WorkflowTemplate for each service but do not want to duplicate the base WorkflowTemplate with all the templates/tasks.
I can somewhat achieve this by using standard templateRef property, but it is a bit more verbose and the arguments/parameters are not merged, meaning that if I want to set a default base parameter in the base WorkflowTemplate, I still have to redefine it in the calling WorkflowTemplate.
---
**Message from the maintainers**:
Impacted by this bug? Give it a 👍. We prioritise the issues with the most 👍.
Contributor guide
Research direction
The issue provides no file or test names. Start by reproducing the failure with a WorkflowTemplate using workflowTemplateRef to call another WorkflowTemplate, then trace entrypoint resolution and parameter merging; done means the reference works and the stated defaults and arguments are preserved.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes
- Domain
- devops
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100