-
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
Group UI nodes based on templateRef
#11106
Comments
Great idea |
Thanks for posting @JPZ13 ! Small addition to |
@mshatkhin23 I love the idea. |
Hey everyone! Here's an example of a "complex" workflow that can be presented a 3 groups: - name: deployment
dag:
tasks:
# First update infrastructure using terraform
- name: terraform-plan
template: terraform-plan
group: infra
- name: terraform-apply
depends: 'task-1'
template: terraform-apply
group: infra
# Then update app backend and frontend
- name: update-backend
depends: 'terraform-apply'
template: argo-update
group: app
- name: update-cdn
depends: update-backend
template: update-cdn
group: app
# Then run validation
- name: backend-e2e-A
depends: update-backend
template: backend-e2e
arguments:
parameters:
- name: test_group
value: "A"
group: validation
- name: backend-e2e-B
depends: update-backend
template: backend-e2e
arguments:
parameters:
- name: test_group
value: "B"
group: validation
- name: backend-e2e-C
depends: update-backend
template: backend-e2e
arguments:
parameters:
- name: test_group
value: "C"
group: validation
- name: frontend-tests
depends: update-frontend
template: frontend-tests
group: validation |
@or-shachar rly like the idea! Could we accomplish this through metadata labels/annotations you think? Although exposing as a top-level task/steps attribute does make things a bit cleaner. We could maybe even have a group-based config field to expose style options? Although this would certainly just be a nice-to-have. For example, groupConfig:
- name: infra
value: '{"color": "red", "border": "blue"}'
- name: app
value: ...
... Also do you imagine |
This comment was marked as duplicate.
This comment was marked as duplicate.
I'd be happy to handle this one |
templateRef
It would be a good bit more complicated to add something new to the spec, especially one that is UI-facing only (i.e. not used by the Controller) vs using an existing field.
Collapsibility I think would be easier than grouping in general, since IIRC the graph layout is entirely algorithmic, based on a Coffman-Graham Sort and not a custom layout. Pluggable sorting/layout algorithms could potentially make sense for #6945 |
After taking a look on how to handle this issue, here is where I am at :
The only drawback I found to handle this only working on the UI, is the missing link between step depending on an other one, represented here in red arrows on this image. We don't have this information at the moment. If you have an insight on this matter that would be really helpful, otherwise, in my opinion it might already be a good step forward and I can start working on implementing that. |
Summary
I was chatting with @mshatkhin23, and he mentioned that he'd like to have the workflow graph grouped based on the workflow template ref. Given this workflow snippet (using templates instead of refs here for simplicity):
It produces the following graph:

We'd like to find a way to group or collapse things based on a given template. In the graph above, it's hard to know which
task-1
is in user-workflow ordag-tier-2
ordag-tier-3
. Ideally we:Use Cases
This should help eliminate confusion when looking at the Argo Workflows graph. As workflows scale and orgs manage lots of templates, there will naturally be naming collisions that arise
Message from the maintainers:
Love this enhancement proposal? Give it a 👍. We prioritise the proposals with the most 👍.
The text was updated successfully, but these errors were encountered: