Feature Requests

we need OIDC with generic Kubernetes clusters for Choas/k8s. current Openid is not for dynamic short time token. we need option here to get short time token. using proper OIDC trust between harness to K8s need to enabled based on K8s connector can use for Choas/k8s. we have currently using Centralized delegate so the delegate need to support OIDC between Centralized delegate to target clusters.

Teams that run Amazon Redshift as a data warehouse cannot manage its schema changes through Database DevOps today, because Redshift is not a supported database platform. Pointing a generic PostgreSQL JDBC connector at Redshift is not a viable path at this such such that it would be great if we could add native Redshift support, including a connector with a connection test and support for the Database DevOps steps (apply schema, rollback, and so on) against Redshift. This lets organizations put warehouse schema changes through the same governed, auditable pipelines they already use for their other databases.

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.

Project-level notification rules for pipeline events currently apply to all pipelines in a project. Please add the ability to filter these rules by pipeline tags, so notifications are sent only for pipelines matching specified tags. For example, we’d like to configure a rule to notify only for pipelines tagged notify: enabled or notification_tier: critical. This would let teams control notification scope without creating separate projects or rules that apply to every pipeline. Ideally, the rule configuration would support matching one or more tag key-value pairs. Use case: We need to send notifications only for selected pipelines in our Sandbox account (MDE1Y2FlM2YtMzg4Yy00ZT), organization sandbox_org, project test

Currently the annotations feature that is gated behind PIPE_HARNESS_ANNOTATIONS requires that you have a GCS bucket to support pipeline annotations in Harness. Not all customers have access to GCS for this feature. I am requesting the support of AWS S3 as a storage backend for these artifacts.

For a Manual Harness Approval stage, I want to dynamically create "allowed values" for an approver Input. Currently, you can dynamically select the default value (with expression syntax) of the approver input, but you cannot dynamically set which allowed values that input has, and which values will be selected by default if it is a multi-selection. This would be an extremely helpful feature for my Dataform implementation. The value for the multi-selection block should be a single string, with separate items separated with a "," and have expression functionality

The SSCA artifact signing and verify steps export the image to a docker-archive tar and cosign reads it whole, so the step's memory grows with the image. A 4.7 GB image needs a 16Gi limit to sign. On Kubernetes build infra sequential steps share the pod and every container gets the largest limit, so every build pod becomes a 16Gi pod. Request: sign the image digest instead of the tarball for keyless (Fulcio) signing, as cosign sign image@digest does, so memory stays constant.

Restore Cache and Save Cache steps don't currently indicate whether a cache was actually restored or saved, the step reports success either way. The only related setting, failIfKeyNotFound, fails the whole stage on a miss, which isn't practical to use just for visibility. Harness Support confirmed hit/miss reporting exists for the newer "restore from Harness" cache step, but not for S3/GCS-backed cache steps on self-hosted infrastructure. We'd like the same reporting extended to those step types, including how much was actually restored. This would let us track time and cost savings from cache restores per pipeline, and identify which pipelines aren't using cache effectively so we can take action

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.

I want to be able to have my step fail on "exit 0" and succeed on errors. In my pipeline, I implement tests, and in usual test strategies we have the "non-passing" cases. So I want to have a step that succeed in case I have an expected error, and fail if the expected error doesn't appear. This would be used to validate that my step properly fails on some expected cases.