Feature Requests

We would to leverage “Dastardly” DAST tool in Harness. Pls do the needful. Dastardly: https://portswigger.net/burp/dastardly

Currently, the pipeline execution history exposes a lot of set fields (e.g. env details, service for CD) that makes it easy for users to find which executions were tied to a specific env or service. The ask is to expand this exposure so that custom attributes can be then searchable. Harness pipeline tags do not quite fit the use case as it is not possible to dynamically add a tag to an execution after the execution kicks off - the tag structure is too rigid to set this. Use case 1: In CI, I dynamically build a number of packages, which is determined programmatically, so it is not directly injectable as an input. One of my steps outputs the list of successfully/failed packages. I would like to "tag" my execution with this array of package names so that in the future, I can search the history and see some of the following metrics for which pipeline executions: built x,y,z package built a/x,y,z package last failed to build x,y,z package etc in a similar manner to how I can search deployments to "prod" today.

The KMS connector only accepts KMS AR stored in Harness Secret Manager. We need an ability to pull those ARN from AWS secret manager.

Feature request as suggest by Harness team to enable system level error retry mechanism for the below failures : - Pod eviction Failure to connect to addon client Connectivity errors between delegate and ci lite engine ref : https://support.harness.io/hc/en-us/requests/72479?page=1

Description: On the DORA Metrics dashboard in Harness, we are currently unable to list more than 50 projects. Additionally, when cloning a DORA Metrics dashboard and manually selecting advanced options (model explore and fields) for Continuous Delivery, GitOps, Deployment, and Service V2, the same 50-project limit applies. This limitation restricts users from being able to list and work with more than 50 projects. Requested Improvement: Allow more than 50 values to be listed and displayed on the DORA Metrics dashboard, both when viewing and cloning the dashboard. This would improve flexibility and usability, especially for users managing larger sets of projects. Steps to Reproduce: Navigate to the DORA Metrics dashboard in Harness. Attempt to list projects – only 50 projects are displayed. Clone the dashboard and try to manually select advanced options for Continuous Delivery, GitOps, Deployment, and Service V2 – again, only 50 projects are available. Acceptance Criteria: The DORA Metrics dashboard should support listing and displaying more than 50 projects. When cloning the dashboard, the same number of projects should be selectable, beyond the current 50-project limit.

The PEM key secret is currently required to be stored in the built-in Harness secret manager. Please add support for storing it in the Vault secret manager.

We'd like a method to be able to test if a secret is resolvable, as per this documentation here: https://developer.harness.io/docs/platform/variables-and-expressions/harness-expressions-reference/#service-expressions Harness supports expressions to check if a value is resolved instead of relying on null checks. The expression <+expression.isResolved(<+pipeline.variables.var1>)> verifies whether a variable resolves to a non-null value. Similarly, <+expression.isUnresolved(<+pipeline.variables.var1>)> can be used to check if a variable remains unresolved. It is recommended to use these expressions instead of <+<+pipeline.variables.var1> != null> for more reliable evaluation in pipelines. The reason for this is to help our teams be able to prepare for cases where it isn't resolvable. We want to be able to use ternary situations to determine what should happen, and using the "is resolvable" doesn't seem to be able to check against the secret.

Please refer to the ticket 77735 It would be a nice to have if harness can support OAUTH for API triggers

Hi, I have a pipeline that reads the secrets (username,password,port) for connecting to the servers. These servers are grouped by environment. Ex: Environment A123 has servers server1, server2, server3. Currently, I define the secret like env123_ser1_username, env123_ser1_password. It will be best, if there is a functionality to group the secrets by environment env123.

As of today, the AWS KMS Connector in Harness does not support the sign/verify use case. Currently, being a secret manager connector, it only supports encryption and decryption.