Feature Requests

Currently, during the initialization step of our build pipeline, multiple health check failures occur before eventual success, resulting in a prolonged initialization of approximately 3.5 minutes. The initialization time on Harness Cloud is significantly longer than expected, and we anticipate a considerable reduction to improve overall build performance.

We'd like to see a method where Harness intelligently caches images for Harness-Managed CI processes. For example, there is no reason why if many customers use alpine, or nginx or other images why Harness should not help reduce Rate Limit strain and also speed up processes for their customers by not caching them. This would benefit Harness and their network costs and increase value to customers.

Our team has had significant issues related to pulling images through Docker Hub. This ticket is being submitted per a request from Harness to do so. We are requesting the "CI_REMOVE_FQN_DEPENDENCY" feature flag to be enabled for account ID: s464IswmR7iEE8qzY-hL1A in the prod2 cluster.

I’d like to request support for a built-in utility or plugin in Harness CI that replicates the behavior of the nrwl/nx-set-shas GitHub Action. The purpose of this utility is to accurately determine the NX_BASE and NX_HEAD SHAs required to run nx affected commands during CI pipelines. This is a common need in monorepo setups using Nx, and the existing GitHub Action cannot be used as-is in Harness due to its dependency on github.context . While we can work around this with shell scripts and GitHub API calls, having an official plugin or step in Harness would: Eliminate boilerplate scripting Avoid external GitHub Action dependencies Improve reliability and native developer experience for Nx monorepos Simplify onboarding for teams migrating from GitHub Actions Desired Behavior: When running on a feature branch, compute NX_BASE from the last successful pipeline run on When running on main, compute NX_BASE from the previous successful main run Expose NX_BASE and NX_HEAD as output variables

We ideally need secure mode communication between the harness delegate and the windows local runner service as I understand the service can be configured to support TLS connections however the harness delegate has no way to pass the required certs so communication fails, can this be delivered?

We need to have the Harness application for our organization configure to use Microsoft SSO EntraID. Do you have a person available we can work with to accomplish this initiative? Thanks

The UI for exposing input elements of container builds is much easier and cleaner than using plugin steps as you can't present out a multi input option like build arguments. We need to use Buildah as we need a non privileged build capability. We'd like buildah to be a supported option in the build steps. Also you should be able to select the "engine" from a drop down to be able to use say Kaniko in one step and Buildah in another.

Hi, need help enabling this feature in my project. Enable Matrix Labels By Name, I need this in project CVU. https://app.harness.io/ng/account/H6rHO8vtQYKelD_wgjnMpA/module/ci/orgs/N4C/projects/CVU/settings/default-settings As per support team in United, looks like this needs a feature flag to be enable it to work. thanks for support

Hi team, We are currently using Harness CI/CD for our pipeline automation and have encountered a limitation. We noticed that the Mail step is only available in the Custom stages, but there is no direct Mail step in the Build stage of the CI pipeline. We would like to request a feature enhancement to enable the Mail step in the Build stage. Looking forward to your response. Best Regards, Kanchi.

We need to setup a delegate configuration which is multi-region. We need to run delegates in 2 EKS clusters in two AWS regions. In each EKS cluster there will be a scalable set of delegates (say min 4 max 8) and all these delegates will use the same tag. User CI load for all users of Harness in our Harness account will use the same tag. We expect the CI load to be spread across all the delegates across the two regions. We had set this config up but the delete/cleanup tasks were not going to the same cluster where the work task was assigned to. This caused pods to not get cleaned up, resulting in resource leaks and cluster running out of resources. We have been running on a single cluster for a while and this is not an acceptable config for a critical service like CI/CD which is used across the many teams. We would like to use this multi-region ASP.