Feature Requests

We are integrating an infrastructure provisioning pipeline with a microservices deployment pipeline. For this flow to be efficient, the deployment pipeline must be dynamic, allowing flexible selection of which services should be deployed. Today, this requires manually creating stages for each service, which does not scale. The proposal is to allow the deployment pipeline (child pipeline) to be dynamically triggered by the parent pipeline based on a list of services, with a simple and user-friendly selection through the UI. This enables orchestrating infrastructure and deployments in a single flow, while keeping the pipeline cleaner, more scalable, and easier to operate.

Currently, when running the TI steps, it fetches the data from the last execution, and based on that, it identifies what tests are run and what are not. The next builds that is executed takes the previous build test timings into consideration and splits the tests accordingly. 1) Instead of considering only the last execution of pipeline, we want this data to be checked by taking an average of all executions, and based on that, do the splitting. Or, 2) Should have a bench-mark build set so that a new build can referr to bench-mark build execution timings for splitting tests to parallel splits accordingly ensuring the overall build time is not increased.

Our leadership and business stakeholders require comprehensive visibility into feature flag configurations across all client deployments. This visibility is essential for Executive Decision-Making, Business Strategy Alignment, Client Success & Risk Management,Compliance & Audit Requirements. I've attached the sample sheet on what exactly they're looking for. Impact Without This Solution: Manual data aggregation is time-consuming and error-prone Delays in executive reporting affect business decisions Lack of visibility creates risk in client feature management Inability to demonstrate feature governance to stakeholders This request has visibility at the executive level, and your support in addressing this requirement would be greatly appreciated.

Description When using HTTP Helm connectors to authenticated Helm repositories where anonymous access is disabled, Helm requires the --pass-credentials flag so that credentials configured on the repo are also sent to the chart download URL (.tgz). Today, the only way to enable this behavior in Harness is to manually configure --pass-credentials in the Helm Command Flags (for example, on the Add command) for each individual Service. This doesn’t scale well when many Services use HTTP Helm repos. Current Behavior HTTP Helm connector is configured with username/password. Helm commands are executed using those credentials. If the underlying Helm repo requires --pass-credentials (for example, when anonymous access is disabled), chart downloads can fail with 401 unless the flag is explicitly set at the Service level. There is no centralized way to opt into --pass-credentials across Services. Requested Enhancement Provide a centralized, opt-in way to apply Helm --pass-credentials for authenticated HTTP Helm repos, for example: A toggle at the HTTP Helm connector level (e.g., “Pass credentials to chart download URL (--pass-credentials)”), or A configuration option at account/org/project level that applies to all Services using HTTP Helm connectors, or Any other global/central mechanism that avoids editing each Service individually. Default behavior should remain unchanged (to stay aligned with upstream Helm), but customers who need this behavior should be able to enable it in one place. Impact / Why it matters Reduces repetitive configuration when many Services use authenticated HTTP Helm repos. Lowers the risk of inconsistent behavior when anonymous access is disabled. Makes it easier to enforce secure, authenticated access to Helm repos at scale.

I previously raised request #98988 regarding an integration issue with JFrog in Harness Components, where I provided all necessary details along with screenshots (Artifact URL, type). However, after submitting this information, it took longer than expected to receive a response. When I did hear back, I was informed that Harness currently supports only Maven artifacts, which was disappointing. I believe this information should have been clarified earlier in the process, either initially or during the information-gathering phase. With that said, I'm now submitting this as a formal feature request. We are seeking support for additional artifact types, specifically: Generic NuGet Docker Could you please provide an estimate of when this feature might be available or if there’s a timeline for its inclusion in future releases? Thank you for your attention to this request. I look forward to your response.

Need an account level configuration to set the Execution History default to something > 30 days. I know we could set a filter to display more than 30 days, but it's a pain as it needs to be setup for every project and is not a default, so it needs to be selected. An acceptable option would be to display < 30 days if there are any recent executions to show, otherwise use the configured default and display executions < the set default. Let me know if this needs more explanation. Thanks, Brian Stevenson

Currently, when connectors display empty references, it's ambiguous whether the connector is truly unused or if reference tracking data is incomplete. This creates uncertainty when teams need to: Audit and clean up unused connectors Assess the impact before modifying or deprecating connectors Understand actual connector utilization across the platform Teams have encountered situations where older connectors showed no references but were still actively processing traffic, leading to hesitation in making necessary infrastructure changes.

Segregation of CI and CD pipelines for easy maintenance and better readability. Folder structure for maintaining CI and CD pipelines based on services or tech stack.

We'd like the ability to run the local runner as a service instead of just executing it directly while in the machine. This is to help improve uptime in case the runner goes down for any reason so we don't have to manually SSH into the machine and reboot the runner every time.

With the Jira integration, it would be valuable to allow users to use JQL to search and filter Jira issues based on their associated feature flags and environments. When integrating with Jira, it’s natural for users to want clear visibility into which Jira issues belong to which feature release, and the ability to query this relationship would greatly improve release tracking, coordination, and overall visibility between Jira and Feature Management.