Workflow Engine
Workflow Engine
Inspect the application facade that registered steps use for release, Git, changelog, backup, and branch behavior.
app/core/workflow/Category
Quick Command
resolved args -> WorkflowConfig -> builder -> WorkflowEngineOverview
The workflow package turns resolved command arguments into one engine that
owns the services and mutable release state needed by pipeline steps. A step is
usually a thin adapter whose execute() method calls one engine method.
Construction Model
WorkflowConfig
workflow_config.py
A dataclass containing commit, tag, version, execution, file, staging, force, remote, backup, and retention inputs used to construct an engine.
WorkflowEngineBuilder
workflow_builder.py
Offers fluent setters, maps supported attributes from resolved command models, validates configuration relationships, and creates the engine.
WorkflowEngine
workflow_engine.py
Copies construction input into runtime fields, creates shared services, holds the active tag and staging state, and exposes one method per workflow phase.
GitContext
pipeline/context.py
Wraps the engine for pipeline execution and exposes its Git service plus optional cross-step fields. Active steps primarily delegate to engine state.
Constructed Services
WorkflowEngine Service Graph
Repository inspection, staging, commit, tag, push, history, branches, and remotes.
Commit-convention checks and Commitizen-related version behavior.
Collect, transform, render, and write changelog content.
Create retained commit and tag message backups.
Coordinate initial and final branch transitions.
Engine Phase Families
Workflow Timeline
Two Orchestration Styles
The active CLI normally uses pipeline profiles whose individual steps call
phase methods on the engine. WorkflowEngine.run() also contains a complete
hard-coded release sequence, but public Run behavior is defined by
PIPELINE_PROFILES, the resolver, and registered steps. Contributors should
not assume that changing run() changes custy run release.
State and Failure Boundaries
- The engine holds mutable tag, tag-message, workflow-case, and staged-file state across phase calls.
GitContextreferences the same engine and Git service; active steps mostly use engine-owned state rather than copying values into context fields.- Engine methods convert many service failures into actionable
ValidationErrorinstances, but the pipeline re-raises and stops. - The engine does not record a transaction log or compensation plan, so a later failure does not reverse earlier effects.
- Dry-run checks exist both in workflow methods and lower-level runner-backed services, but reads, validation, resolution, and prompts can still occur.