Feature Requests

This feature request proposes to enables CV Analysis to compare the same node of the Test Host with the corresponding node of the Controlled Host instead of the nearest node. Specially for a scenario where Dynatrace metrics return multiple services (node) data for the same instance of the application, comparing the same metric of one node with other node is providing the incorrect CV Analysis leading the CV failure.

We'd like to be able to utilize Harness Secrets to store the the plan output from Terraform Plan stages in the same way it happens for the Terraform Apply Stage: https://developer.harness.io/docs/continuous-delivery/cd-infrastructure/terraform-infra/run-a-terraform-plan-with-the-terraform-apply-step/#encrypt-the-terraform-apply-json-outputs This is in order to keep things secret and have a consistent behavior between Terraform stages. It is also for us to be able to ingest the values into container step/container step group processes

I need a way to restrict the use of secrets in pipelines. Examples of restrictions: secrets in this secret manager can only be used against the production environment these secrets can only be used by an account level template Current OPA policy is not sufficient to enforce these restrictions. For example: a pipeline is created that use queries the secret but uses a variable to hold the secret id, <+secrets.getValue(<+variables.foobar>)>. Current OPA policies on pipeline would see the variable expression and not the actual ID. This makes it hard to restrict access to certain secrets without being overly restrictive that prevents other valid use cases. Policy needs the following information: secret ID being accessed secret manager where secret is stored pipeline that is trying to access secret step hierarchy of step trying to access Environment and infrastructure being used for custom and deploy stages service and overrides being used for deploy stage what resource is the secret access defined in

Impact: High, affects onboarding and long-term scalability of GitX usage in CD pipelines Background: While executing pipelines from feature branches using GitX, the CV step fails to display verification results. Although the step technically runs (i.e., verification is performed), attempting to view the results triggers a 500 Internal Server Error. Root Cause (as identified by Engineering): The CV step currently only fetches service and environment definitions from the default branch. Feature branches are not supported for monitored services used in the CV step, which causes a disconnect when executing pipelines from non-default branches. This behavior was confirmed as expected and documented after internal investigation: Monitored Services: https://developer.harness.io/docs/platform/monitored-service/ Verify Deployments: https://developer.harness.io/docs/continuous-delivery/verify/configure-cv/verify-deployments/#step-4-create-a-monitored-service Feature Request: Enable GitX support for feature branches in the Continuous Verification step, so that: Service and environment definitions can be fetched from the feature branch. Verification results display correctly when executing from a non-default branch. Users are not forced to merge changes into the default branch just to verify changes.

Creating Multiple Variables Output are time consuming and not efficient when we need to send different multiple values for each pipeline execution. I want to be able to generate a JSON object for consumption by and API also later in the stages/steps. Lets say I have 20 values I need to export in my pipeline, now I need to define every value in my output step and then. If I could instead generate a JSON object that vas defined as "JsonVariable" and then later in the pipeline (or API) it can collect the data needed during this step. If I create a JSON variable right now as a string, it contains the escaped characters, and when I call this from the API I need to clean up the escaped characters.

Currently unable to roll back the changes made at policy from UI. Require a native feature to roll back to the previous change via the UI.

Per the Flexible Templates ( https://developer.harness.io/docs/platform/templates/inject-step-stage-templates/ ), I see in the notes that you can't insert steps in step group templates, but we require that be added.

Is there any way to restrict what stage or step goes into certain Insert Stage? Use case includes but not limited to: Ensure user does not insert an incorrect stage for purpose For sequential stages, gets inserted with a correct order

Pipeline Stages do not have a default branch setting like other GitEx entities. This causes issues with IDP if the branch is not explicitly defined and the branch is coming back as null.

Hi Harness Team, We’d like to request enhanced support for deploying to VMs in Google Cloud Platform (GCP) using GCP connectors, without requiring direct SSH keys (Linux) or WinRM username/passwords (Windows). Background: In AWS and Azure, Harness supports VM deployments using connectors tied to those platforms, without the need to manually provide OS-level credentials. This improves security posture, simplifies setup, and aligns better with cloud-native identity management. Request: We’re asking for equivalent functionality for GCP — the ability to deploy to GCP VMs (Linux or Windows) via the GCP connector using IAM permissions, metadata APIs, or similar identity-based mechanisms, without the need to configure SSH or WinRM access. Why This Matters: Reduces credential management overhead -Aligns with least-privilege, identity-based access practices Simplifies onboarding and scaling of VM-based deployments This is especially important for organizations standardizing on connector-based integrations and moving away from long-lived OS-level credentials.