Feature Requests

Customer wanted this functionality :- 1.Let user create a new token with the same name if the prior one is revoked. Only restrict on the same active delegate token name. Delete revoked token immediately and a new token with the same name should be allowed.

Hello. While Dynamically provisioning infrastructure with Terraform has been useful https://developer.harness.io/docs/continuous-delivery/cd-infrastructure/terraform-infra/provision-infra-dynamically-with-terraform/ , It has been less useful in its application, since we cannot define things like ServiceDefinition dynamically. Only Task definition can be done so, and as such, this makes it difficult for us to fully utilize a Dynamically Provisioned Infrastructure. We'd like the ability to do so in order to support a 1-step process for our deployments

We need a way to trigger harness pipeline using git tags via git experience. Currently we have the feature to run them from branches only. The feature is needed to be available on the UI as well as some API support as well.

Scenario: You want shell script step output a variable even when script execution fails. An example below. I am checking if DNS name exists. If it doesn't exist I want to fail the step so I can do failure execution strategy of retry mark as success. At same time I want output variable available so I can use the output variable in subsequent steps. However afaik there is no way to do an output variable if you want to mark step as failure. set +e echo "DNS name to test: $dnsname" host $dnsname dnsteststatus=$? echo "DNS test returned status: $dnsteststatus" if [ "$dnsteststatus" -eq 0 ]; then echo "DNS name for $dnsname was found in DNS" else echo "DNS name for $dnsname was not found in DNS" fi Ex script.

Currently Harness will not modify an existing webhook in GitHub when adding a trigger. This makes rotating the secret difficult. The ask here is to have a way in Harness to update an existing GitHub hook for harness with a new shared secret.

Feedback about the “Pipeline Executions” page and the “Deploy Execution History” page. The Pipeline Executions page shows “Open” for builds triggered by a PR regardless of the current status of the PR. It seems to say the state of the PR at the time the build was triggered, which will probably always be “Open.” The Deploy Execution History doesn’t show the artifact tag that is being deployed. This would be very helpful to allow users to see exactly what will be deployed and link that to a build and even a commit>. Also, it would be very helpful to see the commit SHA and message associated with the artifact being deployed

Currently, we need to run 1 very large k8s pod for all of our CI dependencies (during testing) and it requires large k8s nodes and it runs for the entire stage duration. We would like to be able to split the dependencies up and start and stop them at the appropriate times during teh build process to minimise the size of the nodes and more efficiently our k8s resources.

Feature request: Need the ability to dynamically set environment variables for a step, or parse from JSON. This will enable more flexible use of in-stage builders and lessen inputs only needed for certain use cases.

Hello Team, Can you please help us in bringing the overrides for the OPA. We want the Policy-Sets to be enforced at account level and at the same time allow exceptions to few projects. We are also aware on the workarounds but finding few difficulties in maintaining them. So, if you could help us in bringing the overrides to OPA then it will be very useful in designing the exception process in coming days.

Currently, the remote flow works correctly for the default branch. However, we need the OPA policies to work on non-default branches as well.