Feature Requests

With NGINX Ingress deprecated in SMP (through 0.45.0, removed as supported at 0.46.0) and Envoy Gateway becoming the supported ingress via the Kubernetes Gateway API, teams that relied on per-team Ingress self-service lose a clean way to manage their own listeners and TLS certificates. The Gateway-native replacement for that pattern is the ListenerSet (XListenerSet, GEP-1713), and it is not currently supported by the SMP-bundled Gateway API stack. Current state On SMP 0.44.x, XListenerSet resources are not reconciled by the bundled ingress. In practice this means all listeners must be defined centrally on the Gateway resource, there is no delegated, namespace-scoped listener or TLS self-service, and teams remain subject to the Gateway's single-resource listener model and its historical 64-listener limit. Desired behavior SMP should allow ListenerSets to attach to Gateways managed by the bundled Envoy Gateway. Specifically: install the experimental-channel Gateway API CRDs (or provide a supported toggle to do so), reconcile XListenerSet such that resources reach Accepted/Programmed, expose the Gateway's allowedListeners namespace scoping through chart configuration, and let HTTPRoute reference listeners defined in attached ListenerSets. Because the resource is currently experimental upstream, feature-gating and a documented migration path to the standard ListenerSet (expected around Gateway API 1.5) would be appropriate. Use cases Platform teams running SMP who want application teams to self-serve their own hostnames, listeners, and TLS certificates on a shared Gateway without granting write access to the central Gateway resource. Multi-tenant clusters that need to distribute listener configuration across namespaces. Environments migrating from NGINX Ingress that need a Gateway-native equivalent of per-team ingress ownership. Deployments approaching or exceeding the 64-listener limit on a single Gateway. Business value Preserves the developer self-service and separation-of-concerns model that NGINX Ingress users depend on, so the forced migration to Envoy Gateway does not become a regression in team autonomy. Keeps infrastructure lean by supporting a shared Gateway rather than one Gateway (and its associated pods) per team, and reduces the risk that customers stall on the 0.46.0 upgrade because the ingress replacement cannot match their existing operational model.

I'd like to see a centralized Harness.io team managed Slack App such that we can configure it once for our account, and then teams simply have to add it to their channel and pick the channel for the pipeline for notifications. Adding a Webhook for each channel for our Enterprise is challenging as we have IT approvals and/or adding new admins to our own "Slack App" so they have to create a new hook per channel.

We are trying to integrate an external artifactory account with our Harness CI/CD pipeline. The external party wants to authenticate our pipeline using OpenID Connect (OIDC). However, the current Artifactory connector does not support OIDC for authentication, which limits our integration capabilities with OIDC-compliant identity providers. It would be beneficial if the Artifactory connector could support OIDC authentication to streamline our integration process.

We are updating our Sonarqube Server installation to 2025.5.0 shortly and have been given a recommendation that clients interacting with that should use sonar-scanner version 7.1.0 to prevent incompatibility issues. We would like the builtin Sonarqube scan step/plugin to be updated to allow us to specify the updated sonar-scanner version, or use the newer version by default.

provide support to restore cache dependency automatically using npm install for node without using custom path Currently It is supporting for yarn install with default path (.yarn) So If you can also provide support for npm install with default path(node_modules) then It will be really helpful for us.

Cache intelligence is not able to detect the build tool automatically when we run a dot net build with multiple csproj files in a project and we require to add the custom cache path. Can we enable the cache intelligence to support multi project repos?

github connectors can be different for each environment. CD pipeline need to switch connector for each env so that it can still connect with same DBSchema but github connector expression resolved to env specific connector name

Description Today, when a Harness pipeline is triggered through the API using a service account token, the pipeline execution is attributed to the service account. This is expected for automation, but it creates an audit gap for organizations where a trusted external system authenticates real users and then triggers Harness deployments on their behalf. Request: provide a supported API-level delegated attribution model for pipeline executions triggered by service accounts. The desired capability would allow a trusted service account to pass a verified end-user identity, such as an email or Harness user identifier, when calling the pipeline execute API or custom webhook endpoint. Harness would then display the execution as being requested/executed by that end user, or clearly show the execution as performed by the service account on behalf of that user. Example desired display: Executed by: user@example.com Triggered via: deployment-service-account or Executed by: deployment-service-account on behalf of user@example.com This should not simply overwrite audit history. The audit record should preserve both identities: * the authenticated automation principal/service account that made the API call; * the delegated/requesting end user from the trusted external system. Use Case An enterprise uses an external deployment portal or internal platform where users are already authenticated and authorized. That system calls the Harness API using a service account token to trigger a CD pipeline. For audit/SOX compliance, the deployment record in Harness needs to identify the real user who requested the deployment, not only the service account used by the external automation layer. Requested Behavior Add a supported field, header, or property to the pipeline execute API and/or custom webhook flow, such as: onBehalfOf requestedBy delegatedUser executedByUser The feature should allow customers to pass a verified user identity for display and audit attribution. Why This Matters For regulated environments, deployment audit records need to answer both: Which automation principal called Harness? Which real person requested or approved the deployment in the external system? Today, customers can pass the requester as a pipeline variable or metadata field, but that does not update the native Harness “Executed by” / execution history attribution. A first-class delegated attribution model would make API-triggered deployment records more useful for compliance, SOX evidence, and audit review.

Currently, in the platform, when changes occur, the YAML DIFFERENCE is available in the UI, showing a before-and-after view of changes. However, this level of detail is not available when exporting the audit log stream. The export only reflects that something was changed (e.g., "edited variable") but does not provide the specific changes (before-and-after details). It would be very helpful to have the exported audit log include the same verbosity, showing the before-and-after state, just as it is displayed in the UI.