G
Garnet Cricket
Problem Statement
Harness CD currently does not support having more than one Canary Deploy/Delete step pair within a single stage. This limitation blocks migration and modeling of complex deployment pipelines that rely on multiple canary strategies defined at the stage level, even when only one canary path executes at runtime.
Current Limitation
During a Canary Deploy, Harness stores ECS service details as an outcome keyed by the step’s fully qualified name (FQN). The corresponding Delete step retrieves this outcome using the same key.
When more than one Canary Deploy step exists in the same stage:
  • The Delete step cannot reliably resolve the correct FQN
  • The Delete step defaults to the first Canary Deploy defined in the YAML
  • This causes delete failures or incorrect behavior when the executed Canary Deploy is not the first one defined
CD today assumes a single deployment strategy per stage and was not designed or validated for duplicate Canary Deploy/Delete steps within the same stage definition, even if only one executes at runtime.
Why Existing Workarounds Are Insufficient
  • Providing an explicit service name in the Delete step does not resolve the issue
  • The service name is typically the same across canaries
  • The failure is caused by incorrect FQN resolution, not service identification
  • Splitting each canary strategy into its own stage significantly increases pipeline complexity
  • This diverges from existing pipeline designs
  • It makes parity-based migration from other CD tools impractical
  • It introduces unnecessary stage sprawl
Use Case
Organizations migrating complex CD pipelines often define multiple canary strategies within a single stage, executed conditionally or sequentially. These pipelines expect the Delete step to always target the canary deployment that actually ran.
Without support for this pattern, teams are forced to redesign pipelines instead of migrating them, which becomes a blocker for large-scale CD adoption.
Requested Enhancement
Add first-class support for multiple Canary Deploy/Delete step pairs within a single CD stage, including:
  • Reliable association between a Delete step and the Canary Deploy step that executed
  • Outcome storage and retrieval that does not rely solely on FQN uniqueness
  • Full compatibility with rollback, post-production rollback, instance sync, and related CD workflows
This should be treated as a formal enhancement and validated across all affected CD behaviors.
Business Impact
  • Enables parity migration from other CD platforms
  • Reduces pipeline complexity and redesign during onboarding
  • Expands support for advanced ECS blue/green and canary deployment patterns
  • Removes a hard blocker for customers with mature CD workflows
Created by Gino Orvieto
·