Execution Model

🚀Pipeline Execution Model

Implementation-Aligned

Trace the active runtime from resolved CLI configuration to the last registered step.

Commandcusty run PROFILE

📦Category

Pipelines

🚀Quick Command

CLI input → profile resolution → build → sequential execution

---

resolverregistrycontextfailure behavior

---

Overview

The Run command does not execute a profile name directly. It resolves CLI and project configuration, expands the selected profile names into step definitions, builds concrete step objects, and passes one shared runtime context through the resulting sequence.

---

Runtime Lifecycle

🕒From Command to Completion

1

Resolve command inputs

Combine command options, project configuration, and global dry-run, debug, and logging values.

completed

2

Register step classes

Register every built-in step name before a pipeline is built.

completed

3

Resolve profiles

Expand nested profiles; merged profiles are deduplicated and globally ordered.

completed

4

Build services and context

Create the workflow engine and wrap it in the shared GitContext.

completed

5

Build the pipeline

Instantiate each resolved step through the StepRegistry.

completed

6

Execute sequentially

Run every step with the same context while updating the Rich progress display.

current

---

Single and Multiple Profiles

✨Resolver Behavior

🔄One Profile

Nested profile references are expanded while the profile's declared order is preserved.

📦Several Profiles

Expanded steps are combined, duplicate names are removed, and the global phase order is applied.

⚠️Unknown Name

Resolution fails before the pipeline is built.

❌Circular Reference

Nested profile expansion raises an error when it detects a cycle.

ℹ️Input order is not execution order

For multiple profiles, Custy uses its global phase priorities: initialization, validation, preparation, generation and editing, backup and cleanup, execution, branch cleanup, then finalization. Writing push commit does not force push to run before commit.

---

The Exact Ordering Rule

• With one recognized profile, Custy expands nested profile references and preserves the declared sequence. It does not re-sort that single result with STEP_ORDER.
• With two or more profiles, Custy expands each profile, concatenates their steps, keeps the first occurrence of each name, and applies a stable numeric sort using STEP_ORDER.
• A step with no priority entry receives the fallback value 999 during a merged-profile sort.

See Step Priority and Ordering for all 27 entries and a complete worked example.

---

Shared Runtime Context

Every step receives the same GitContext. It exposes the workflow engine, Git service, optional Commitizen helper, and mutable runtime values such as the resolved tag, workflow case, and files selected for staging. This lets one step prepare state that a later step consumes without recreating services.

---

Progress and Failure Semantics

The active Run pipeline displays a Rich progress indicator and advances it only after a step succeeds. When a step raises an exception, Custy stops the progress display, identifies the failed step, re-raises the error, and does not execute later steps.

🛡️A stopped pipeline is not rolled back

Earlier file writes, commits, tags, or pushes may already exist. Determine the last successful stage and inspect local and remote state before choosing a recovery action.

---

Two Pipeline Presentations

custy run uses the progress-enabled Pipeline. Some focused commands use SimplePipeline, which executes the same registered step contract with simpler logging. This difference affects presentation, not the requirement that each step implement execute(context).

---

Continue

🚀Related Commands

Commands commonly used together with this command.

Profiles

See what each public name resolves into at a practical level.

Step Priority and Ordering

Review the exact single- and multi-profile ordering rules.

Custom Composition

Understand merged-profile normalization.

Step System

Review the internal contracts and source responsibilities.