Feature Requests

even when the send status to git option is manually disabled in the security stages, the pr checks are being added on to the github pr. We need the option to work in the required way such that if it is disabled manually, we stop getting the checks on the pr.

When deploying a service to multiple infrastructure definitions within the same environment in parallel, the Resource Constraint incorrectly serializes the deployments by queuing one behind the other. Even though the infrastructures are completely distinct. Current behavior: The Resource Constraint scopes its concurrency lock at service + environment level. As a result, two deployments targeting different infra definitions in the same environment are treated as competing for the same slot, and one is held in queue until the other completes. Expected behavior: The Resource Constraint should scope its lock at service + environment + infrastructure level, so that deployments to distinct infrastructure definitions within the same environment can proceed in parallel as configured. Steps to reproduce: Configure a pipeline with a multi-infrastructure deployment stage with parallel execution enabled Use two or more infrastructure definitions scoped to the same environment Trigger a deployment and observe that one infra's stage is queued behind the other at the Resource Constraint step Impact: This directly undermines the parallel execution setting in multi-infrastructure deployments and adds unnecessary deployment time, particularly in environments with multiple target hosts or infra definitions.

It would be helpful if a Step's (or stage's) matrix values could be access by a subsequent step/stage in the pipeline. (Perhaps: <+pipeline.stages.MyStage.spec.execution.steps.MyStep.Matrix...>) This would allow the next step (eg MyNextStep) to dynamically interrogate specific instances of the matrix step. For example if MyStep has a matrix of [alpha,bravo,charlie], resulting in executed steps of MyStep_alpha, MyStep_bravo, and MyStep_charlie, then currently MyNextStep needs to either be hardcoded to read values from these steps or perform complex parsing of the entire pipeline file. However with this feature MyNextStep could read the matrix value directly.

Harness currently supports traffic splitting for Istio when using the sidecar data‑plane mode by configuring Istio VirtualServices with weighted routing rules. Istio now also supports the Kubernetes Gateway API, where traffic routing is defined through HTTPRoute resources and enforced at waypoints in Ambient Mesh. The legacy Istio custom CRDs (e.g., VirtualService, DestinationRule) are now in a frozen status, with no new feature development planned, as the Gateway API has become the standard configuration model. We require Harness to Full support for Gateway API–based traffic management, alongside continued compatibility with the older, now‑frozen Istio CRDs.

We'd like the ability to set global environment variables that persist across Script Steps. Currently, Harness supports this for CI stages and Run steps where you can set Stage/Pipeline variables and have them added as env variables but, for Script Steps in Custom and CDS stages, this does not work. Part of our requirement is to use elevated AWS permissions during the pipeline execution and use lower AWS permissions when a pipeline is not running. To this extent, we need to persist the AWS Credential env vars across Script Steps.

currently the update release repo step auto creates files and updates params. Provide an option to fail the step if file does not exist.

Currently, CV steps only support the manual credentials for pulling the Azure metrics. We need support for WIF and other authentication methods to pull the metrics in CV.

We have a scenario where we want separate dev/stage/beta/prod pipelines that can all be ran independently. Currently, we allow a successful dev pipeline to trigger the stage pipeline. However, in the future, we'd like a successful stage pipeline to then trigger the beta pipeline and beta to trigger prod. We cannot currently do this as Harness gives a yaml compliation/validation error at the dev level that it does not support 'nested pipeline triggers'. Is this something that Harness could support? Or do you have suggestions on alternative ways to keep independent env pipelines but also be able to have one 'uber' pipeline that could successfully run all 4 in sequence?

introduce manual approval step or pause GCP Cloud run deployment • Deploy without traffic • Shift 10% traffic (canary) • Run automated validations • Include a manual approval step • Then shift remaining traffic to clarify - is metric a prerequisite to include a manual approval step

Hi Team, We are trying to trigger the CICD pipeline based on the curl statements, but while doing I need to provide completed set of input sets. Instead I wanted to select specific stages for inputset rererences