[X] I have tested with the :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.
[X] I have searched existing issues and could not find a match for this bug
Both of these are enabled by default. This means that my workflow that uses no templateRefs now just shows the root node by default. This confuses users like me who don't like change.
I would strongly recommend that they are off by default.
Version(s)
v3.6.0-rc3
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.
It really doesn't matter what you run but I had this in my clipboard anyway... so have a free workflow...
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: many-nodes-
annotations:
workflows.argoproj.io/description: |
This example flips a coin many times and prints the result. It should only say heads 1 in 20 runs (statistically).
spec:
entrypoint: coinflip
templates:
- name: coinflip
steps:
- - name: flip-coin
template: flip-coin
- - name: heads
template: heads
when: "{{steps.flip-coin.outputs.result}} == heads"
- name: tails
template: coinflip
when: "{{steps.flip-coin.outputs.result}} == tails"
- name: flip-coin
script:
image: python:alpine3.6
command: [python]
source: |
import random
result = "heads" if random.randint(1, 20) == 1 else "tails"
print(result)
- name: heads
container:
image: alpine:3.6
command: [sh, -c]
args: ["echo \"it was heads\""]
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?
3.6 RC3 comes with some new dag filter buttons:
Both of these are enabled by default. This means that my workflow that uses no templateRefs now just shows the root node by default. This confuses users like me who don't like change.
I would strongly recommend that they are off by default.
Version(s)
v3.6.0-rc3
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.
It really doesn't matter what you run but I had this in my clipboard anyway... so have a free workflow...
Logs from the workflow controller
Logs from in your workflow's wait container