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.

I’d like to request support for a built-in utility or plugin in Harness CI that replicates the behavior of the nrwl/nx-set-shas GitHub Action. The purpose of this utility is to accurately determine the NX_BASE and NX_HEAD SHAs required to run nx affected commands during CI pipelines. This is a common need in monorepo setups using Nx, and the existing GitHub Action cannot be used as-is in Harness due to its dependency on github.context . While we can work around this with shell scripts and GitHub API calls, having an official plugin or step in Harness would: Eliminate boilerplate scripting Avoid external GitHub Action dependencies Improve reliability and native developer experience for Nx monorepos Simplify onboarding for teams migrating from GitHub Actions Desired Behavior: When running on a feature branch, compute NX_BASE from the last successful pipeline run on When running on main, compute NX_BASE from the previous successful main run Expose NX_BASE and NX_HEAD as output variables

Currently, when a pipeline fails in Harness, the default notification payloads (e.g., email, Slack) include a helpful errorMessage field that captures the cause of the failure, such as: "errorMessage": "Shell Script execution failed. Please check execution logs." However, when using custom notifications via JSON notification templates, this field is not available as a variable, preventing customers from including critical error context in their custom messages. Feature Request: Expose the errorMessage field in custom notification templates for the following failure types: Step failure (eventType: StepFailed) Stage failure (eventType: StageFailed) Pipeline failure (eventType: PipelineFailed) Use Case: This enhancement would allow customers to build richer and more actionable custom alerts — especially for use cases where notification delivery is routed to internal tools, messaging platforms, or monitoring systems that rely on structured JSON. Example: In the default notification payload for a failed step, the following structure is provided: { "eventData": { "pipelineName": "Simple Pipeline with Runtime Inputs", "stepName": "ShellScript_1", "eventType": "StepFailed", "nodeStatus": "failed", "errorMessage": "Shell Script execution failed. Please check execution logs.", ... } } We would like to have the errorMessage field accessible in the custom notification template so we can include it in our Slack/webhook payloads.

I would like to request the ability to publish test reports from a Run step within a Custom Stage or Step Group. These types of stages are used to execute QE automation scripts and will provide a lot of benefits for viewing results and providing summary of state of automation test runs.

We'd like a method to be able to see EOS/EOL status a lot easier. Currently, the process is to look at a docs page which is not linked to in the Harness Console and is not frequently updated We need a method so that our teams can be informed ahead of time. Here are some suggestions: API to allow for tracking of the EOS/EOL status of each delegate version. This can be a list with the information UI Changes/backend changes - Show Minimum supported version/last version available for EOS, and others that are EOL - Flag delegates with an icon for EOS and EOL status Notification process - customers to be notified about delegates that go into EOS and EOL status - warn customers a month in advance about the EOS EOL Status

We need a tool in Harness UI for Housekeeping tasks such as scheduling the removal of old logs (e.g. > 1y), experiment runs and logs (> 3y), etc. We want a minimum retention of 3 years(Configurable value) post the retention period. Older logs and Artifacts(DB entries) should be removed.

Currently, output variables of type Secret are only supported for the Run and Shell Script steps. We'd like this functionality extended to Plugin steps as well. Use Case: We have a plugin that generates a short-lived GitHub token and returns it as an output variable, which subsequent steps in the pipeline use. We're looking for a way to instruct Harness to treat this output as a Secret, ensuring it is masked in logs, UI, and other exposed locations for security purposes.

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.

All pipelines are messed up, i can see CI pipeline in CD and CD pipeline in CI. Need this enhancement to segregate based on CI and CD pipeline.

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.