Feature Requests

We require the ability to send custom commands, specifically kubectl commands, to the respective Kubernetes clusters. This feature would enable us to manage and interact with our Kubernetes environments more directly and flexibly.

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 Team , Can you please enable CI_DYNAMIC_BRANCH_SELECTOR for the account

We would like fields that have multiple allowed values to allow for the setting of a default value that has multiple values. We would like to set multiple values by CSV. This can be accomplished by editing the YAML directly, but Harness has advised that this is not an officially supported process and may break at any time. The Backend engineers advised that default values are expected to be a single value. However, if we allow for the selection of multiple values, Harness should set default values to allow for multiple selection from a usability perspective. This should be supported for longer term usability best practices

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 ?