Feature Requests

Description Today, when a Harness pipeline is triggered through the API using a service account token, the pipeline execution is attributed to the service account. This is expected for automation, but it creates an audit gap for organizations where a trusted external system authenticates real users and then triggers Harness deployments on their behalf. Request: provide a supported API-level delegated attribution model for pipeline executions triggered by service accounts. The desired capability would allow a trusted service account to pass a verified end-user identity, such as an email or Harness user identifier, when calling the pipeline execute API or custom webhook endpoint. Harness would then display the execution as being requested/executed by that end user, or clearly show the execution as performed by the service account on behalf of that user. Example desired display: Executed by: user@example.com Triggered via: deployment-service-account or Executed by: deployment-service-account on behalf of user@example.com This should not simply overwrite audit history. The audit record should preserve both identities: * the authenticated automation principal/service account that made the API call; * the delegated/requesting end user from the trusted external system. Use Case An enterprise uses an external deployment portal or internal platform where users are already authenticated and authorized. That system calls the Harness API using a service account token to trigger a CD pipeline. For audit/SOX compliance, the deployment record in Harness needs to identify the real user who requested the deployment, not only the service account used by the external automation layer. Requested Behavior Add a supported field, header, or property to the pipeline execute API and/or custom webhook flow, such as: onBehalfOf requestedBy delegatedUser executedByUser The feature should allow customers to pass a verified user identity for display and audit attribution. Why This Matters For regulated environments, deployment audit records need to answer both: Which automation principal called Harness? Which real person requested or approved the deployment in the external system? Today, customers can pass the requester as a pipeline variable or metadata field, but that does not update the native Harness “Executed by” / execution history attribution. A first-class delegated attribution model would make API-triggered deployment records more useful for compliance, SOX evidence, and audit review.

Currently, Harness is supported until Helm v3. As Helm v4 is available and wanted same support in Harness Delegate. We raised a support ticket (#100574) to enquire about the same. And support team also confirmed harness delegate is certified for Helm v3 only. Raising this feature request for Helm v4 support in Harness

Our current requirement is to drive adoption of these policies like the vulnerability count of New critical/high, and we want every developer to be aware when their pipeline has warnings. Requiring users to switch off the console view and manually check the Policy Enforcement section defeats this purpose, as it adds unnecessary steps and reduces visibility. Additionally, even if developers switch to the normal view, they would first need to know that a step-level policy exists and that it can generate warnings or errors. Expecting this level of awareness isn’t practical and limits the effectiveness of policy enforcement. Ideally, these warnings should be displayed directly in the pipeline UI or logs, ensuring developers can easily notice and act on them without having to change views.

Argo has a CLI command to directly trigger a rollback to a previous version of the deployed Application. This can also be run from the Argo UI. Link - https://argo-cd.readthedocs.io/en/stable/user-guide/commands/argocd_app_rollback/ This request is to add support for the same operation from the Harness GitOps UI in two places: As an operation in the Application details page, potentially in the ‘previous deploys’ list page (select which one we want to roll back to, and select the “Rollback” option for it). Alternatively, as a popup that appears when a “rollback” operation is selected from the three dots menu for the application. As a GitOps Rollback step that takes an application id and a rollback version as parameters.

We want our developers to be able to create triggers for pipelines and looking at the Roles we are not seeing a specific rules for triggers . In Roles under pipeline we do see Create/Edit which looks like give permission to create Triggers aswell . With that it also let the Developer capability to create pipeline which we want to avoid . Basically we want to seperate the trigger permission out of Pipelines . You can check #55628 for reference that i created and was suggested to create a Feature Request

Gathering data from steps to pass from stage to stage can be confusing for developers consuming templates. An ability to pass this information into a stage level output similar to how stage variables work for input would be extremely useful. An example could be a complex stage which includes build of a container image could pass the full image path and separately pass the registry, image name, tag and SHA so these are more easily passed into the deploy stage for selection of the image to deploy.

I see that when I checked old runs of the pipelines, I do not see the pipeline executions for the pipelines that are deleted. Ideally, I would want to still have the history of the execution even if the pipeline is deleted as it would help track the deployment history and change that deployed in the past.

Problem statement: When working with templated steps/step-groups/stages, a major aspect of their utility is their capacity to be freely reused in multiple contexts. When working from within the yaml editor, it is possible to apply such constructs as 'when' clauses to templated steps, step-groups, and stages, and having access to these 'when' clauses allow for appropriate data encapsulation. However, this has the drawback that when the reference to the template is updated (whether by explicit change of version or through requiring reconciliation) the 'when' clause is removed (and requires manual review to catch and restore). By contrast, when using the GUI, the only option is to create conditionals which reference variables defined outside their contextual frame, and there is no clear means for templates to advertise which variables they rely upon, nor are there top level decorators exposing how the steps/step-groups/stages do run conditionally, when they are templates. Sample use story: I have a templated step-group which I want to be using, conditional on a value calculated earlier in the pipeline, e.g. 'determined that there is an additional client jar target to build'. I want to be able to use a jexl expression at the top level to directly reference the calculated value (from within the UI), rather than having to rely on conditionals on the template which are blindly referencing variables defined outside their contextual frame, or manually writing the conditional in yaml & needing to worry about possibly losing the conditional when updates take place. Several possible options: (*) (minimal) allow for the UI to support some kind of parameter ~slots for conditionals, so that there isn't a need to use blind exterior references when defining template conditions, and update the UI to consistently decorate conditionally executing templated steps/step-groups/stages. (*) (more general, but has potential issues depending on defaults) establish a way to enable templates to have conditions added to them at the calling level. This request is directed to both CI and CD pipelines

Currently CI and Security Stages natively support Github status checks. This feature for CD is being requested by several of my customers.