Feature Requests

Currently, the GitOps application Helm values configuration does not support supplying values as native structured types, such as objects, arrays, booleans, etc. This limitation requires us to either encode complex Helm values as strings or rely on indirect values files.

context: https://support.harness.io/hc/en-us/requests/111968

Custom Webhook triggers support header conditions to authenticate inbound requests, but a secret expression (e.g. referencing a stored secret by name) used as the expected value in a header condition does not resolve at trigger-firing time. It evaluates to a literal null instead of the secret's actual value, so any header condition written this way can never match, and the event is silently rejected after the initial 200 acknowledgment. Today, the only workaround is to either move the check into the first pipeline step (which requires letting the pipeline start before authenticating) or hardcode the literal secret value directly into the trigger's header condition, which defeats the purpose of storing it as a secret in the first place, and only works if the sending system supports a custom header name. What we'd like Support resolving secret expressions when they're used as the comparison value in a Custom Webhook trigger's header condition, so a webhook can be authenticated at the trigger level using a securely stored secret, before a pipeline execution is created. Why it matters Many third-party systems that send custom webhooks (for example, experimentation or feature-flag platforms) sign or authenticate their webhook deliveries with a fixed header name and a shared secret value, and don't support arbitrary custom header names. Without secret resolution at the trigger level, teams integrating these systems with Harness triggers are forced to either expose the secret value in plaintext inside the trigger configuration, or push authentication logic into the pipeline itself, which still executes (and consumes build minutes) before the request is verified. Example A webhook sender delivers a request with a fixed header (e.g. x-webhook-key: <64-char key> ). The trigger's header condition is configured to compare this header against a stored secret's value. The condition never matches because the secret expression resolves to null at evaluation time, so the trigger event is always rejected, even though the header value sent is correct and verified byte-for-byte against what's configured. Today's workaround (and why it's not enough) Hardcoding the literal secret value into the header condition works around the resolution gap but reintroduces the exact problem secrets exist to prevent: a sensitive credential stored in plaintext inside the trigger configuration. Moving authentication into the pipeline instead means unauthenticated requests already trigger a pipeline execution, which is both a security gap and a wasted resource cost.

I have to select every service, override, input-set, pipeline and move them to git manually. It would be far easier to select all or multiple and move them at once

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.

Currently, the GCP OIDC connector is only available in Harness specific steps. However, to authenticate within a generic run step there is no connector available and one has to work around it by downloading the service account and mounting it as a secret. There is inherent risk in this approach. Being able to use the GCP connector in the generic Run steps would be extremely helpful.

In relation to https://ideas.harness.io/feature-request/p/insert-stage-step-restrictions , we would like to request for insert stages to be able to be ran in parallel. This aims for us to have a 1:1 insert step to template ratio and define a specific pattern for our tenants with steps and stages that can run in parallel.

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.