Feature Requests

Summary Improve the "Variables" search functionality in the Pipeline execution/editor view to provide precise scoping (definitions vs. references) and direct navigation to search results. Problem: Currently, the search feature in the Pipeline Variables modal can be misleading and lacks actionable navigation: Scoping Confusion: Searching for a term returns a count of matches (e.g., "13 results found"), but these often include references (usage in YAML) rather than just definitions (the actual variables). This makes it difficult for users to distinguish between where a variable is created and where it is simply being used. Lack of Visibility: The UI indicates the number of results but does not highlight where the matches are within the variables list or the pipeline structure. No Navigation Path: While users can cycle through results (X of Y), there is no hyperlink or "jump-to" functionality to take the user to the specific stage, step, or YAML line where the term was found. Proposed Solution Search Categorization: Differentiate between "Variable Definitions" (found in the variables list) and "Variable References" (found in steps/expressions). Visual Highlighting: Auto-scroll to and highlight the matching variable within the side modal when cycling through results. Navigation Links: Provide a "View in Pipeline" or "Go to Step" link for each search result so users can immediately see the context of the variable usage. Contextual Metadata: Display the location of the match (e.g., Found in: Stage "Deploy" -> Step "Shell Script") directly in the search results list.

Description: What problem are you trying to solve? When configuring a pipeline in Harness CD (Pipeline Studio), selecting an Environment or Infrastructure Definition requires scrolling through a flat dropdown list with no search functionality. At scale, where organizations manage dozens or hundreds of environments, this makes pipeline authoring slow and frustrating. What would you like to see? A type-to-filter / search input inside the Environment and Infrastructure Definition dropdowns in Pipeline Studio. As a user types, the dropdown should narrow in real time to show only matching entries, consistent with how other selectable fields work across the Harness platform. Why is this important? Reduces time spent configuring pipelines. Reduces risk of selecting the wrong environment when lists are long. Improves usability for enterprise customers operating at scale. Aligns the experience with other Harness modules (e.g., Connectors, Services) that already support searchable dropdowns. Who is impacted? Any Harness CD user who works with a large number of Environments or Infrastructure Definitions, particularly enterprise customers.

In progressive canary, when we do the deployment, the HPA splits based on the percentage defined on the live traffic. But in standard Canary, it just creates a replica of the same HPA resources, without checking the percentage. As a result, if someone has defined 1 replica or any replica percentage, it is not respecting that and is creating a default HPA. We have a higher minimum value in the HPA, due to which the number of instance we are defining or the percentage is not getting respected. Link to the doc how it works in progressive canary - https://developer.harness.io/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-executions/create-a-kubernetes-progressive-canary-deployment#horizontal-pod-autoscaler-and-pod-disruption-budget We need similar in the standard as well.

Summary EKS clusters with OPA Gatekeeper enforce runAsGroup. Harness supports Pod Spec Overlay for CI stage Kubernetes infrastructure, but Container steps in Custom stages don’t expose Pod Spec Overlay or a runAsGroup field, causing admission failures unless users manually edit YAML per pipeline/step. Current Behavior Custom-stage Container step UI exposes Run as User / Run as Non Root / Privileged / Capabilities, but not runAsGroup or Pod Spec Overlay. Adding podSpecOverlay directly in YAML works, but must be repeated everywhere. Request Allow a default/inherited Pod Spec Overlay at Kubernetes infrastructure/connector/account/org/project level applied to all K8s step executions (CI + non-CI).

We are a SMP customer, and need OIDC authentication to Artifactory for Docker connectors. OIDC is being mandated for all connections, and needs to be applied wherever possible per our leadership.

We would like to see more granular failure types that we can use for Failure Strategies. For example, actions on 401 errors vs 403 errors vs 400 errors all fall under authentication but, we want separate actions to happen based on what error code is returned.

Currently, monitored services cannot be dynamically provisioned based on the query, source, and threshold. Thresholds are hardcoded and must be defined separately for each monitored service. We need to use a single template across all monitoring services. However, since some fields do not support expressions, we cannot currently use monitored services as templates. As a result, we need to maintain separate monitored services for each service and environment. The end goal is to manage monitored services dynamically through YAML, with all fields passed dynamically. Also, does Harness automatically create monitored services when syncing the .harness folder? Regards Anurag Sinha

We use the Harness CD product's ASG feature to manage our AWS Auto-Scaling Groups. In particular, this means using the "ASG Rolling Deploy" step with a ASG Configuration and Launch Template file. When we use the ASG Config/Launch Template files, Harness manages the ASG according to those files. E.g. we have certain AWS tags we want added to every ASG and Launch Template created by Harness. Those are defined in the configuration files, and on every deploy, Harness creates or updates the tags on the resource in AWS to match those in the configuration exactly. We have other teams within our company that want to centrally insert certain tags onto AWS resources. Currently, every time we run an ASG deploy, Harness sees the centrally-added tags, and wants to delete them, as they are not in the service's configuration files. We'd like to be able to configure the Harness ASG deploy step to "ignore" certain tags, e.g. when it creates or updates an autoscaling group or launch template, it should act as though any tags in the "ignore" list do not exist. Harness should not attempt to modify or delete ignored tags. We manage other resources via Terraform, and the AWS Terraform provider has had a feature for some time allowing us to ignore tags: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/guides/resource-tagging#ignoring-changes-in-all-resources Our ask would be to implement a similar feature in Harness.

There is no option to move an initially created DPELOYMENT TYPE template inline to remote.

Needed support for OIDC with generic Kubernetes clusters. The OAuth 2.0 Password Grant Type has serious security ramifications and should not be used. According to the OAuth spec on security best practices ( https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#name-resource-owner-password-cre ): "The resource owner password credentials grant [RFC6749] MUST NOT be used. This grant type insecurely exposes the credentials of the resource owner to the client." Need to revamp the OIDC integration with kubernetes.