Recognize nodes, ports and edges

01Open the workflow

Objective

Read what the card announces before entering the editor.

Actions

1. Open the project from Overview.
2. Read the line under the workflow name.
3. Select Open in editor.

Overview → project → first-workflow → Open in editor

What you should see

The card summarises the workflow in one line: its trigger and how many jobs it orchestrates. Draft and never run describe the file and its history, not its validity.

first-workflow
Manual · 2 jobs
Draft   never run

02Read the workflow graph

Objective

Identify the four executable nodes and the direction of the edges between them.

Actions

1. Stay on the Workflow configuration tab.
2. Read the counters beside the workflow name.
3. Follow the arrows from left to right, then select the PowerShell node.

Workflow configuration → select a node

What you should see

Five nodes for four steps: the fifth is the container, which never executes. Each node carries a blue handle on the left and on the right — an edge always leaves a right handle and enters a left one, so the graph reads in one direction only.

first-workflow   5 nodes · 3 edges   Valid
first-job → second-job → action_log_1
                      → action_powershell_2

03Read the containers

Objective

Understand what a container is, and what it is not.

Actions

1. Look at the header of the red container around the two jobs.
2. Open its On child failure list.
3. Close it again without changing the value.

Error Scope → On child failure

A container never executes. Hydra's runner never sees one. What it does is copy a policy onto the nodes it encloses when the YAML is written — so you set the rule once, in one place, instead of on every step.

What you should see

Three values, and only three. fail stops the workflow, skip marks the step skipped, continue carries on. A child that sets its own value keeps it — the container fills in the blanks, it does not overrule.

On child failure:
  skip
  continue
  fail

04Open the first job

Objective

Switch scenes and read a job as a straight line from source to destination.

Actions

1. Select the Jobs configuration tab.
2. Pick first-job in the tab bar at the bottom.
3. Read the header of the container around the first two nodes.

Jobs configuration → first-job

What you should see

Three executable nodes in a row — source, transformation, destination — plus the container. The palette also changes: Sources, Transformations and Destinations replace Actions and Jobs, because those have no meaning inside a job.

first-workflow / first-job   4 nodes · 2 edges   Valid
orders.csv → transform_filter_3 → firtered_orders.csv
Retry Scope   Retries 4 ×, delay 5 s

05Open the second job

Objective

Confirm the shape repeats, and meet the container that changes nothing.

Actions

1. Select second-job in the tab bar.
2. Read the three nodes and the two edges.
3. Look at the container header — it has no option.

Jobs configuration → second-job

What you should see

The same source-transformation-destination line, this time reading the file the first job wrote. The Sequence container carries no setting because it applies no policy: it is there to make a long chain readable.

first-workflow / second-job   4 nodes · 2 edges   Valid
src_orders_clean → transform_select_4 → dst_sales_by_region
Sequence   (no option)

06Read what a node is configured with

Objective

Open the four connector nodes and see that each holds only what its role needs.

Actions

1. Double-click the source of first-job.
2. Close it, then open the Filter node, then the destination.
3. Switch to second-job and open its source.

double-click a node → read → Cancel

Every dialog shows the same three parts: a step name you choose, the fields required by that node type, and a read-only node ID. The name is what appears in the YAML; the ID is what the canvas uses internally and never changes.

CSV  SOURCE        step name · file path · node ID
Filter  TRANSFORMATION   step name · expression · node ID
CSV  DESTINATION   step name · file path · node ID

07Read the two actions

Objective

See what an action is, and why one of them is tied to the operating system.

Actions

1. Return to Workflow configuration.
2. Open the Log node, read its message, cancel.
3. Open the PowerShell node and read its command, working directory and timeout.

Workflow configuration → double-click an action

Both dialogs carry a Run condition (when). Left empty, the step always runs; filled in, it runs only when the expression is true. That is how a Condition node upstream steers the rest of the graph.

Log         ACTION   message
PowerShell  ACTION   command · working directory · timeout (60 s)

08Read the DSL the canvas produces

Objective

Connect what you have been reading on screen to the four files on disk.

Actions

1. With a job open, select Hydra DSL in the top bar.
2. Walk through the four tabs in order.
3. Close the panel.

Jobs configuration → Hydra DSL

A job is not one file but four, and the panel gives one tab to each. Read them in this order and the job explains itself: where the data comes from, what happens to it, where it goes, and how the three are wired together.

sources:          source id  → type, connection, extract
transformations:  steps      → one operation per entry
destinations:     dest id    → type, connection, load
pipeline:         from: <source id>   to: <dest id>

09Read the workflow the canvas describes

Objective

See the whole orchestration as one file, and find each thing you read on screen inside it.

Actions

1. Compare each name below with a node on the canvas.
2. Compare each depends_on with an edge.
3. Look for the containers — and notice they are absent.

hdrctl workflow validate ./workflow.yaml

Four steps, in the order the graph imposes. first-job starts alone, second-job waits for it, and the two actions both wait for second-job — so they run in parallel, because nothing links them to each other.

version: "1.0"
workflow:
  name: first-workflow
  trigger:
    type: manual
  steps:
    - name: first-job
      type: job
      job: ./jobs/first-job
      depends_on: []
      on_failure: skip

    - name: second-job
      type: job
      job: ./jobs/second-job
      depends_on: ["first-job"]
      on_failure: skip

    - name: action_log_1
      type: action
      action: log
      params:
        message: "test the log"
      depends_on: ["second-job"]

    - name: action_powershell_2
      type: action
      action: powershell
      params:
        command: Get-Process
        timeout: 60
      depends_on: ["second-job"]

The Error Scope is nowhere in this file, and neither are the other two containers. All that survives is the on_failure: skip it wrote on each of its children. That is the whole contract: you draw a container, Hydra writes a policy.

✅ Workflow valid — no errors detected.