Feature Requests

Description: Customers are unable to import Harness API Docs into Postman: Downloading openapi-merged.json fails. Importing openapi-merged.yaml causes Postman to hang. Expected Behavior: openapi-merged.json should download successfully. openapi-merged.yaml should import into Postman without issues. Impact: Prevents effective API testing and slows developer workflows.

Many pipelines generate a run-specific JSON report (e.g., deployment summary, compliance results). Today, Harness email notifications can include text and variables, but they cannot attach the JSON file that was just produced by the pipeline. Teams resort to workarounds (upload to S3/GCS and share a link), which is clunky and risky. Currently, when a pipeline generates a file (e.g., a deployment report or status JSON), the only way to share it with recipients is by either embedding the content into the email body or hosting it externally (e.g., S3) and sharing a link. It would be very useful if Harness provided the ability to attach a file (e.g., JSON) generated during pipeline execution directly to the email notification. This will help teams share pipeline artifacts more effectively with stakeholders without relying on external storage or manual steps. ✅ Impact: Improves notification efficiency, enables better auditability, and reduces dependency on external storage systems. 🚀 Target Users: DevOps engineers, release managers, SREs, QA teams, and stakeholders receiving deployment updates.

This has come up a few times recently around how/when a users 'name' is updated on login via SAML specifically. On initial/first login, it is populated with contents of displayName, subsequent logins this is skipped. So if you onboard a lot of users for example, it will default the name field to their email address and leave it in this state until manual operations are performed. Proposal: On successful SAML assertion received: * Check for attribute displayName in assertion * Verify it is not null * if != null, compare to current value in UI and update to new value if there is not a match. This will reduce the amount of manual toil involved in writing scripts and editing user entries one at a time whenever displayName is not properly sent on the first user login for example. In this path, it will dump the users email address in the name field until manual intervention is taken.

With larger enterprises willing to use Harness's IP allowlisting feature, its important to have a bulk IP upload API since today both UI and API only have options for individual IPs.

Are there instructions for getting dependabot to update image references in harness yaml templates/pipelines? I note dependabot supports k8s already and the functionality is very close, both follow the image: foo/foo:1.1 format

Currently, getting x509 certificates to work as one would prefer, depending on what area of the product you are dealing with can range anywhere from difficulty level of 2 to 10 in some cases it seems. I propose that a button be added to the installer screen (Helm, Docker, etc) that permits you to upload one or more(properly formatted bundle) of x509 certificates. This would essentially require providing an archive vs. copy and paste in most cases. Once unarchived, either have a simple installer that deploys the new delegate with the certificate/bundle volume and vol mount, and from there make sure these certs are available everywhere possible a platform module may require them. This would inherently reduce the amount of support tickets re: certificates(quite a few) if implemented correctly.

Requirement: Walgreens has an AKS policy that forbids the deployment of a container with no upper-limits on CPU and Memory (GRD088). Harness Limitation: Whereas the Harness delegate helm chart allows passing in these upper-limits for the delegate deployment (ie, inside harness-delegate-ng/templates/deployment.yaml), the same chart does not have this option for the delegate upgrader job (ie, inside harness-delegate-ng/templates/upgrader/upgraderJob.yaml). Consequence: Due to this limitation, Walgreens will not be able to enable the auto-upgrade feature of the delegates. We're asking the Harness team to allow the passing in of resource limits to the upgrader Job.

I'm looking to get access to OIDC connects and Google secret manager. Is this possible.

I need a way to prevent the platform from assigning arbitrary tasks to a delegate. It would be helpful if the platform could restrict delegate usage to specific tasks by either assigning users to it via RBAC or requiring a delegate selector to be specified. This would ensure that delegates are only used for their intended purposes and not for unrelated tasks.

Customers would like the ability to restrict a delegate’s usage to a defined set of projects/pipelines, even when those projects span across multiple orgs. Currently, if a delegate is scoped at the account level, it is technically available for all projects and teams. The only workaround today is to place all projects into a dedicated org and scope the delegate there. This is not feasible when the customer’s setup spans multiple orgs. Sample Use Case: Customer has a team that purchased dedicated hardware for CI builds. This hardware should only be used by specific pipelines/projects owned by that team, but their projects span across multiple orgs, so creating a single org to scope the delegate is not an option. Current Behavior: Delegates scoped at the account level are available to all projects. No way to enforce restrictions using OPA, RBAC, or other policy mechanisms. Requested Behavior: Ability to explicitly restrict which orgs/projects/pipelines can use a delegate, even if the delegate is scoped at the account level.