Feature Requests

CD containerized group step only supports kubernetes. The request would be to have this orchestrated on a VMs

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

We have many applications onboarded to Harness GitOps ArgoCD Platform. However, we dont see an option to send the notifications of GitOps events mentioned below: We request you to add this feature for minimum below events: OnSyncSucceeded OnSyncFailed OnHealthDegraded OnAppNotSynced (or OutOfSync) If we have these notifications as a feature, we can create a robust feedback loop that keep our team informed about successful deployments and immediately alerts to the critical failures or health issues, ensuring us to maintain the stability and integrity of applications.

Hi Harness Team, I’ve implemented rollback stages in our CD pipeline and am currently working on enhancing the notification stage. Specifically, I want to dynamically include the name of the failed stage in the notification content. To achieve this, I attempted to use the expression <+pipeline.stages.<stageName>.status> within the HTML body of the notification. However, it does not seem to retrieve the failed stage name during rollback. Based on our findings, it appears that enabling the CDS_ALLOW_EXPRESSION_RESOLUTION_PIPELINE_ROLLBACK feature flag is necessary for this functionality to work as expected. I kindly request that this feature flag be enabled for our account. Thank you for your support! Best regards, Sagar Shelki

Hi Harness Team, I’ve implemented rollback stages in our CD pipeline and am currently working on enhancing the notification stage. Specifically, I want to dynamically include the name of the failed stage in the notification content. To achieve this, I attempted to use the expression <+pipeline.stages.<stageName>.status> within the HTML body of the notification. However, it does not seem to retrieve the failed stage name during rollback. Based on our findings, it appears that enabling the CDS_ALLOW_EXPRESSION_RESOLUTION_PIPELINE_ROLLBACK feature flag is necessary for this functionality to work as expected. I kindly request that this feature flag be enabled for our account. Thank you for your support! Best regards, Sagar Shelki

Hi, we use input as our version that gets released. Trigger passes the value to input and that is used to get artifact for ecs or lambda deployment. When we go to the execution history, its a very basic requirements for us to see what we have just deployed, what was the release/input. Can we please add the value of the input on the execution history view? Can we please also add the last execution input on the pipeline view?

Hi team, When setting up gitOps agent, we would need to provide the username and personal access token. During our test to try to by pass some changes from harness side by granting certain permission to the bot with the same username, we saw this message: (Author = Harness.io ","prnum":30,"repo":"skynet-users/legion-release-harness-config","source":"policy/bot_commit_policy.go:79","time":"2025-06-27T00:49:55Z","user":"harness-cd"} In this specific case since Author is set to " Harness.io " instead of "harness-cd" ( which should be the correct username), we could not bypass branch protection, I was wondering if we can make Author = user ?

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.

We are utilising cloud run functions within google cloud and would like to have the cicd process with harness. For this we will need the CDS_GOOGLE_CLOUD_RUN feature flag enabled. Thanks, Cormick

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.