Feature Requests

Currently, the GSM connector only supports pulling secrets from 1 project. This means that if our secrets are spread across 100 projects, we need to create 100 connectors. Just how multi-project OIDC support for GKE + Cloud Run was released, please add this feature to Google Secret Manager plugin too. GKE : https://developer.harness.io/docs/continuous-delivery/deploy-srv-diff-platforms/kubernetes/define-your-kubernetes-target-infrastructure/#enable-cross-project-access Google Cloud Run: https://developer.harness.io/docs/continuous-delivery/deploy-srv-diff-platforms/google-cloud-functions/google-cloud-run/#enable-cross-project-access

FIS global has requested to support user group in E-Mail Step. This will help them to provide the user group for sending E-mails instead of manually adding all the users.

When external secret manager token is rotated , we need to reset the perpetual task for the triggers.

Add the functionality in "External Tickets" ( https://developer.harness.io/docs/security-testing-orchestration/jira-integrations/ ) to automatically create a Jira ticket when an exemption is raised.

Customers using file-based triggers in Harness CI have observed that pipelines are being executed when a pull request is merged, even if the target directory (e.g., flutter/) was not directly modified in the merge commit itself. The root cause appears to be that GitHub includes all files changed in the source branch when a merge commit is created. Harness currently evaluates the changedFiles condition against this expanded list of files, causing the trigger to fire even if the actual merge did not change the target directory. Current Behavior: Triggers with a condition such as changedFiles: flutter/.* will run if those files were changed at any point in the source branch, even if the final merge commit doesn’t modify them. There is no built-in way to detect merge commits at the trigger level and apply different logic. Requested Enhancement: Introduce support for detecting and optionally ignoring merge commits in trigger evaluations. This could take the form of: A new trigger condition (e.g., isMergeCommit: false) The ability to evaluate only the files changed in the actual merge commit, not in the full history of the source branch A toggle or flag in the trigger UI/API to exclude changes from merge commits Workaround (Currently Required): Users must add a pipeline step to manually inspect the commit metadata and skip execution if it’s a merge commit: a non-ideal solution for CI/CD automation. Impact: This enhancement would prevent unnecessary pipeline runs, reduce execution overhead, and provide more precise control over file-based triggers, especially in monorepos and enterprise-scale workflows.

For build executions, we would like to be able to view actual pod usage metrics (CPU, memory, and disk) within the Harness UI. Currently, the only way to view these metrics is by viewing logs within our clusters.

Description: Customers managing large user bases need a way to automatically deactivate users who have not been active within a customizable period of time (e.g., 30, 60, or 90 days). This functionality supports compliance, platform hygiene, and license optimization, particularly in regulated industries or organizations with strict security and access controls. Requested Functionality: Native support for setting an inactivity threshold (e.g., "Deactivate users after X days of inactivity") Admin control over what counts as "activity" (e.g., login, build runs, deployment triggers) Ability to exclude specific users or groups (such as service accounts) Optional notifications to admins prior to deactivation Reporting or dashboards showing users flagged for deactivation Current Workaround: Manual user audits and scripting against Harness APIs to identify and deactivate inactive users. This is not scalable or efficient for large orgs. Value to Customers: Helps meet compliance or internal policy requirements around stale user access Improves platform security by automatically removing dormant users Optimizes license usage under user-based pricing models Reduces manual administrative overhead

We require the ability to send custom commands, specifically kubectl commands, to the respective Kubernetes clusters. This feature would enable us to manage and interact with our Kubernetes environments more directly and flexibly.

We need a comment section for each occurrence of an issue. This will allow us to provide our analysis, especially in the case of a true positive, for future reference. Having the option to add comments to a specific occurrence would be very helpful for developers or testers to better understand the context whenever they revisit the issue.

Due to a large number of clients with varying deployment configurations, we have pipelines that have close to 100 input sets. When the pipeline changes we are required to reconcile each input set individually. This is VERY cumbersome. Please provide a button (or an option on the ellipsis) on the pipeline that will reconcile and save all input sets. As per ticket #87746, the support representative verified that this feature does not exist.