Compose your jobs into a workflow
Wrap the cumulative job in a manual workflow, add a completion action, and validate the manifest and dependency graph before running either step.
1. Objective
Goal
Create workflow.yaml beside first-job. Declare one job step and one dependent log action, then use hdrctl workflow validate workflow.yaml to prove the model and graph are valid.
Keep working from the cli-course folder. The job is named first-job, and the workflow lessons add workflow.yaml beside it; every command and terminal excerpt in this lesson was run against that same cumulative project.
Reading a result. Durations and process identifiers vary between machines — ignore them. What proves a run is the stable evidence: named files, resolved identifiers, row counters, step states, HTTP status. If one of those differs from the lesson, fix the previous step before continuing.
Prerequisites
- Lesson 8 completed and checked.
- The validated
first-jobCSV project. - A terminal opened in the
cli-coursefolder.
2. Steps
01Declare the workflow identity
Objective
Create the top-level workflow mapping and manual trigger.
Actions
- Create
workflow.yamlincli-course. - Set the name to
first-job-workflow. - Keep the trigger manual for this guided run.
workflow:
name: "first-job-workflow"
description: "Run the guided CSV job, then record completion."
trigger:
type: manual
The document has the required top-level key, a unique name, and a supported trigger type.
workflow:
name: "first-job-workflow"
trigger:
type: manual02Add the job step
Objective
Reference the existing cumulative job from the workflow directory.
Actions
- Add
run_first_jobundersteps. - Set
typetojobandjobto./first-job. - Leave
depends_onempty.
steps:
- name: "run_first_job"
type: job
job: "./first-job"
depends_on: []
on_failure: fail
The first step points at a configured job and has no upstream dependency.
- name: "run_first_job" type: job job: "./first-job" depends_on: []
03Add the completion action
Objective
Create a second step that can run only after the job succeeds.
Actions
- Add an
actionstep namedrecord_completion. - Use the implemented
logaction. - Depend on
run_first_job.
- name: "record_completion"
type: action
action: log
params:
message: "first-job-workflow completed successfully."
depends_on: ["run_first_job"]
on_failure: fail
The dependency forms a simple job-to-action sequence.
run_first_job → record_completion
04Validate the workflow graph
Objective
Check the workflow model and dependency ordering without executing it.
Actions
- Run the workflow validator against the new file.
- Do not use
workflow rununtil this verdict is clean.
hdrctl workflow validate workflow.yaml
The observed validator output is a single successful verdict.
✅ Workflow valid — no errors detected.
3. Checklist
| Verification | Expected result |
|---|---|
| Top-level key | workflow |
| Job path | ./first-job |
| Dependency | record_completion depends on run_first_job |
| Validation | Workflow valid — no errors detected. |
4. Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
| The top-level key is rejected | The document starts directly with name or steps | Nest the definition below workflow: |
| The dependency is unknown | The referenced name differs by spelling | Use the exact earlier step name run_first_job |
| A cycle is reported | Steps depend on each other in a loop | Keep the first dependency empty and the second dependent only on the first |
5. Next lesson
The workflow manifest and DAG are valid, but neither step has executed yet. The next lesson runs the workflow and reads one terminal state for the job, one for the completion action, and the final two-of-two summary.