Feature Requests

Application teams would like to have a way to 'lock' a pipeline so that further builds cannot overwrite their changes while QA and dev teams validate. An option like Jenkins had to 'temporarily disable this pipeline' from running would be very handy.

Currently, it is very difficult to see who created a feature flag. It would be good to have that showcased under the feature flag details.

Currently Harness support custom dashboard metrics. Is it possible to get in-built Cloud Monitoring dashboard metrics as well?

Customers would like the ability to restrict a delegate’s usage to a defined set of projects/pipelines, even when those projects span across multiple orgs. Currently, if a delegate is scoped at the account level, it is technically available for all projects and teams. The only workaround today is to place all projects into a dedicated org and scope the delegate there. This is not feasible when the customer’s setup spans multiple orgs. Sample Use Case: Customer has a team that purchased dedicated hardware for CI builds. This hardware should only be used by specific pipelines/projects owned by that team, but their projects span across multiple orgs, so creating a single org to scope the delegate is not an option. Current Behavior: Delegates scoped at the account level are available to all projects. No way to enforce restrictions using OPA, RBAC, or other policy mechanisms. Requested Behavior: Ability to explicitly restrict which orgs/projects/pipelines can use a delegate, even if the delegate is scoped at the account level.

Enhancement to the product's usage reporting capabilities, specifically for Monthly Tracked Keys (MTKs). The goal is to provide engineering and product teams with direct visibility into which Feature Flags (FFs) are consuming the highest volume of MTKs. This information should be easily accessible, ideally within the existing product dashboard or via an automated notification mechanism, to allow teams to proactively manage usage and prevent unexpected overages without manual reports.

This is a request to have the ability to use Kubernetes secrets as a secret store for Harness pipelines. Automatic discovery of Kubernetes secrets that have a specific annotation would be great as it would allow for less terraform use on the platform. The objective of this is to be able to use something like External Secrets Operator to connect to many different secret stores that may be used in a target cluster and simply just observe the secrets that we need to in an allowed namespace.

In order to support BitBucket authentication for user accounts and the upcoming deprecation of App Passwords, we would like Harness to support API token authentication as advised by Bitbucket: https://www.atlassian.com/blog/bitbucket/bitbucket-cloud-transitions-to-api-tokens-enhancing-security-with-app-password-deprecation Please provide us this new feature so that we can continue to utilize our connectors.

It would be good for our team to be able to enforce standard naming conventions that make sense for our team

Allow Harness to retain the state of previous stages, enabling users to make decisions such as re-running only failed test cases. Users should have the ability to re-run failed stages or tests directly from the UI, or via an out-of-the-box solution

When taking a look at execution data, we want a method to filter out existing data from pipelines that have already been deleted. At this time, there is no method to do this, since the execution filters only look at execution data information and don't cross-reference against Pipeline data.