Feature Requests

I need to create a stage template for ECS Deploy, which includes all deployment strategies. However, when I try to place blue/green with traffic shift in one step groups and another blue/green with swap (in parallel and conditional to define which one will be executed), it's as if there were only a single 'create service' and then in that case the swap doesn't work. I don't think it makes sense that I need to have two different stage templates (which increases rework/maintenance) to handle both strategies.

Problem When using "Rerun from Last Failed Stage" in Harness CD pipelines, the system fetches the latest pipeline YAML from the configured branch rather than using the original pipeline version that was used during the failed execution. This creates non-deterministic behavior and false failures in incident recovery scenarios. Current Behavior: Run pipeline with YAML commit aa → Test passes, Prod fails Pipeline updated to commit bb (adds new outputs/variables) "Rerun from Last Failed Stage" on original execution → Harness uses commit bb Result: Output/context mismatch causes false failures Desired Behavior: "Rerun from Last Failed Stage" should use the original pipeline commit (aa) from the failed execution Ensures deterministic reruns and maintains pipeline context consistency Use Case This is critical for: Incident Recovery: Production support teams need reliable reruns without pipeline drift Debugging: Isolating whether failures are stage-related or due to pipeline changes Confidence: Reduced false positives when resuming failed stages Related Context There is an existing "Rerun Pipeline with Original Pipeline Definition" setting (Account Settings → Default Settings → Pipeline), but: It reruns the entire pipeline from the start, not from the failed stage This defeats the purpose of "Last Failed Stage" rerun for long-running multi-stage pipelines We need both capabilities: stage-level resumption + original definition pinning Impact Non-deterministic pipeline behavior False failures due to pipeline definition drift Reduced reliability of rerun feature for production support workflows Prior context: https://support.harness.io/hc/en-us/requests/121843

GitOps MergePR and UpdateReleaseRepo steps serialize Git operations per connector token using an internal "Git Restraint" lock (limit 1, FIFO) to avoid secondary rate limits on the Git provider. If the lock-holding step's completion event is ever lost, the lock never releases and has no recovery path short of the TTL (6 months). Every subsequent step against that token queues and eventually times out ( MARK_EXPIRED ) with no indication in the step logs of what it's actually waiting on. Today, unblocking requires a support escalation and a manual database fix by Harness engineering. What we'd like A self-service way for account/project admins to view and release a stuck Git Restraint lock (API and/or UI action) instead of relying on Harness engineering to clear it from the database. A "Git Restraint" command unit surfaced in the MergePR step's execution log, analogous to what UpdateReleaseRepo already shows, so a queued/blocked step clearly reports that it's waiting on the lock (and ideally which execution holds it) rather than showing no logs at all until it expires. Why it matters Right now a stuck lock is invisible to the customer until every Merge PR step using that connector token starts timing out, and the only way out is a support ticket plus a manual backend intervention. Self-service visibility and release would let teams unblock themselves in minutes instead of hours, and would surface the disableGitRestraint workaround as an informed choice rather than something support has to explain after the fact. Example We hit this on a production account: a Merge PR step's lock-release event was silently dropped during a brief consumer-lag incident, leaving the lock ACTIVE for ~17.5 hours. Every Merge PR step across the account using that connector token queued behind it and expired at the 10-minute step timeout with zero log output, until Harness on-call manually deleted the lock document from the database. Today's workaround (and why it's not enough) disableGitRestraint step parameter skips the lock entirely, but that reintroduces the risk of secondary Git provider rate limiting it exists to prevent. The only other option today is filing a support ticket and waiting for Harness engineering to manually clear the lock from the database, which is exactly what extended the incident above to ~17.5 hours.

Problem Statement Currently, declaring harness_platform_gitops_applicationset requires translating the entire ApplicationSet specification into nested HCL schema blocks. Argo CD ApplicationSets natively rely on YAML and often incorporate embedded Go/Helm templating syntax (e.g., conditional blocks like {{- if .baseValuesPath }}). Translating these constructs into pure HCL is rigid, error-prone, and adds unnecessary friction when translating back to YAML under the hood. Proposed Solution Introduce an optional raw YAML attribute (e.g., yaml_body, spec_yaml, or manifest) to the provider resource. This would allow users to supply the ApplicationSet definition directly via Terraform's standard functions like file() or templatefile(), bypassing the need for extensive HCL translation. Use Case Example Configuring dynamic Helm value files with conditional Go templating inside an ApplicationSet: YAML valueFiles: {{- if .baseValuesPath }} - $values/{{ .baseValuesPath }} {{- end }} - $values/{{ .valuesPath }} ignoreMissingValueFiles: true Expressing this conditional syntax natively in Terraform HCL blocks is impractical. Supplying raw YAML via standard templatefile() preserves native Argo capabilities. Key Benefits Native Argo Compatibility: Allows teams to re-use existing Argo ApplicationSet YAML manifests directly without manual HCL refactoring. Preserves Templating Logic: Eliminates schema conflicts when using Go/Helm template tags inside manifest blocks.

Make ServiceNow plugin compatible with Australia version

Today I can connect to ClickHouse and run queries through Custom Health, but the integration is difficult to manage. ClickHouse’s HTTP query endpoint expects raw SQL in the POST body or as a URL query parameter, while Harness Custom Health appears to expect a JSON POST body. Because of this, I have to URL-encode the SQL and pass it as a GET/query parameter in the Harness UI. I also have to write SQL that shapes the result into Harness-specific JSON instead of mapping native query result columns to CV fields. For example, a native integration should allow users to configure the endpoint, auth, database, query, timestamp column, value column, serviceInstance column, and optional grouping/metric fields. For enterprise use, the current workaround is fragile and hard to manage across many services and CV queries. Without native ClickHouse support, teams may need ETL jobs or custom wrappers just to make ClickHouse data usable for CV.

Please add support for dynamic metric series in Harness CV Custom Health metrics (and other metrics sources for that matter). I am attempting to use the Custom Health connector with ClickHouse and need CV to compare sets of time series during canary/rolling verification, rather than requiring one query/config per metric. As I understand it, the response shape currently groups values only by serviceInstance: {"data":[{"serviceInstance":"5f64b5d498","metricValues":[{"timestamp":"2026-08-14 02:07:00","value":1}]}]} I would like the same envelope to support a dynamic metric key per value: {"data":[{"serviceInstance":"5f64b5d498","metricValues":[{"metric":"merchant1234|reasonCode123|gateway456","timestamp":"2026-08-14 02:07:00","value":1}]}]} Harness CV should group/analyze each unique metric key independently across baseline/canary. This would support high-cardinality/dimensional metrics by letting a ClickHouse GROUP BY produce multiple CV-analyzed series from one configured query.

Please enable PIPE_ENABLE_DEPENDENCY_BASED_EXECUTION for account mVtnzk9LQtWDLS9ef8O6Ow (CareSource, org EES_Enrollment). We'd like it account-wide, as we expect to use DAG for the remaining ADO pipeline migrations rather than just FET-MMS

When we are using inputs, we have long length fields which get cut off and are hard to edit in the approval stage. Requesting to be able to expand this so it is easier for the user to edit the information in the field.

We need support for PowerShell 7.5+ CLI in Harness delegates, as of now, the Harness delegate only supports the 7.0 CLI version. Please add support for the same.