Feature Requests

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.

We need the ability to visualize and report on GitOps deployments within Custom Dashboards, as the current "Deployments and Services V2" data source only covers standard CD pipeline stage executions. Since our projects rely heavily on GitOps, the exclusion of this data means we cannot accurately track active environments, deployment frequency, or sync statuses. Currently, filtering by environment only reflects data from active CD pipelines, completely ignoring our actual GitOps activity. We need Harness to introduce a way to map and track GitOps deployments within the dashboard widgets so we can gain comprehensive visibility into our real deployment metrics and provide accurate reporting to our stakeholders.

For some reason it seems like deployment type templates are not supported by the move to git operation. Support suggested we get an enhancement request open to get this supported. Technically there's ways to do this by modifying the YAML directly, but we would like this supported natively.

Feature request to get all the modules that are specific to Step Group as Step For example , git clone

Feature request to get some of the modules that are specific to Step Group as Step Like for example, git clone.

We are looking for a centralized mechanism within Harness where policy exceptions can be recorded, reviewed/approved with validity periods, and then automatically considered during OPA policy evaluation so that approved exceptions do not result in policy enforcement failures. With this managing and tracking OPA policy exception within the Harness UI would really help to provide better control.

Would it be possible to include a git clone step in CD and the Custom stage as well? If container-based execution isn’t needed, there doesn’t seem to be an option for it. Its for DB developers which are not that good in scripting so can we have a plugin or native for the same.

We have been building pipeline templates with insert stages as our primary driver of pipelines, and in some cases we also have stage templates that themselves contain insert steps, for wrapping team-code with common tasks like environment build up/tear down logic, however we noticed we cannot insert the stage templates with the insert steps into our pipeline templates' insert stage, which breaks a flow that would otherwise be very helpful to us. I noticed that this is listed as a limitation in the insert stage docs, but I would love to see if we could get this limitation lifted to allow for the nesting of a stage template with insert steps into a pipeline's insert stage.

Summary Currently, in the Release Orchestration (Release Management) module, there is no native option to re-run an existing release. If a release needs to be executed again (e.g., due to a transient failure or a requirement to repeat a specific release cycle), users must manually create an entirely new release. Problem For customers with complex release structure, creating a new release from scratch for every re-execution is a redundant manual effort that introduces operational overhead and slows down the delivery lifecycle. Proposed Enhancement Add a "Re-run" or "Restart" action for a Release. This should allow users to: Trigger the full release orchestration again using the existing configuration. Ideally, choose between re-running the full release or resuming/re-running from a specific failed stage. Maintain a link or history between the original release attempt and the re-run for auditability. Impact This will significantly improve the developer experience by reducing the manual steps required to handle release repetitions or failures, ensuring a more streamlined and efficient Release Orchestration workflow.

Currently, Harness AI features for Continuous Delivery (CD) on Self-Managed Enterprise Edition (SMP) rely on a fixed external endpoint ( https://harness.openai.azure.com ). For organizations running SMP, particularly in regulated industries or air-gapped/offline environments, this creates a blocker, as security and compliance policies often require the use of internally approved LLMs rather than external SaaS-hosted models. Harness Agents already support a BYOM model via LLM Connectors, allowing teams to connect Anthropic, OpenAI, or Gemini, including self-hosted model endpoints. We would like to see this same capability extended to Harness AI features in CD on SMP, so that teams can: Connect a company-approved or self-hosted LLM for AI-powered root cause analysis and deployment troubleshooting in CD pipelines Use a custom endpoint (e.g., an internal model deployment) via the existing AIModel connector type Maintain full compliance with internal data residency and security policies This would bring SMP customers to feature parity with SaaS for AI-driven CD capabilities, while respecting enterprise governance requirements.