Allow Pipeline Chaining (Pipeline Stages) in Pipeline Templates
P
Prospective Walrus
Pipeline templates currently cannot contain chained Pipeline stages. This prevents organizations from composing governed, reusable “golden” pipeline templates with independently owned build, deployment, verification, and testing pipelines.
This is an unexpected gap between two core Harness capabilities. Pipeline templates are intended to provide standardization and reuse, while pipeline chaining is the native mechanism for composing workflows and passing outputs between them. The documentation also creates a reasonable expectation that this should work: template best practices state that pipeline templates support all stage types, and the dedicated pipeline-chaining documentation does not identify pipeline templates as a limitation.
Without this support, platform teams must either:
- Embed every optional or team-specific workflow into an increasingly large golden template.
- Duplicate pipeline logic as stage or step templates.
- Copy and detach pipelines from their governing template.
- Trigger other pipelines through API or webhook workarounds, losing native input/output mapping, execution-graph visibility, status propagation, retry behavior, and governance.
Common use cases include:
- Passing an image digest produced by a build pipeline into a reusable deployment pipeline.
- Running a service-owned regression, smoke, or post-deployment test pipeline after a standardized deployment.
- Deploying an ephemeral service and optional mocks before running external browser or integration tests.
- Composing provisioning, database migration, security, performance, chaos, promotion, or cleanup pipelines around a standard release process.
- Allowing platform and application teams to own and version their parts of a delivery workflow independently.
Requested behavior:
Allow a pipeline template to define a type: Pipeline stage with the same capabilities available in a non-templated parent pipeline, including:
- Selection of a concrete child pipeline.
- Runtime input and output mapping.
- Consumption of child outputs by subsequent stages.
- Conditions, failure strategies, and looping strategies.
- Existing RBAC and inline/remote SCM behavior.
- Referencing child pipelines that are themselves backed by pipeline templates.
Templates do not need to become directly executable objects. It is sufficient for concrete parent and child pipelines instantiated from templates to participate in chaining.
For an initial implementation, the existing restriction on recursive or nested pipeline chaining could remain. The essential requirement is support for a single-level chained pipeline stage within a pipeline template.
This would allow organizations to keep golden templates small, governed, and reusable while giving individual teams a clean extension mechanism for specialized workflows.
Log In
P
Prospective Walrus
We understand the concern that unrestricted nesting across step, stage, and pipeline templates could create an expensive and confusing input-resolution graph. We are not requesting arbitrary recursive nesting.
We are requesting a constrained, single-level pipeline composition boundary: after a pipeline template is resolved into a concrete parent pipeline, that pipeline should be allowed to execute a Pipeline stage using the existing pipeline-chaining contract.
The child pipeline should be treated as an opaque component. The parent should see only the child pipeline’s explicitly declared pipeline-level inputs and outputs—not the inputs of every stage, step, or template nested inside it. Both pipelines could be created from templates, but chaining would occur between the resulting concrete pipeline entities.
Reasonable initial guardrails would be:
- Continue to prohibit nested pipeline chaining and circular references.
- Require a fixed child pipeline reference rather than runtime pipeline selection.
- Expose only explicitly declared pipeline-level inputs and outputs.
- Do not flatten transitive child-template inputs into the parent run form.
- Require reconciliation or validation when the child pipeline’s input contract changes.
This limitation does not eliminate complexity; it transfers that complexity to customers. Teams must duplicate child-pipeline logic as stages or steps, build increasingly large monolithic golden templates, detach pipelines from template governance, or use API, webhook, and shared-variable workarounds that lose native execution visibility, status propagation, retry behavior, RBAC, and input/output mapping.
A typical example is a governed deployment template invoking a service-owned post-deployment regression pipeline and passing it the deployed image digest, environment, and endpoint. This is a normal reusable workflow boundary and directly matches the purpose of pipeline chaining.
We are not asserting that unrestricted nesting should be supported or that implementation is trivial. We are asking Harness to consider a deliberately limited form of pipeline chaining within pipeline templates rather than treating it as equivalent to arbitrary nested template resolution.