Feature Requests

even when the send status to git option is manually disabled in the security stages, the pr checks are being added on to the github pr. We need the option to work in the required way such that if it is disabled manually, we stop getting the checks on the pr.

When deploying a service to multiple infrastructure definitions within the same environment in parallel, the Resource Constraint incorrectly serializes the deployments by queuing one behind the other. Even though the infrastructures are completely distinct. Current behavior: The Resource Constraint scopes its concurrency lock at service + environment level. As a result, two deployments targeting different infra definitions in the same environment are treated as competing for the same slot, and one is held in queue until the other completes. Expected behavior: The Resource Constraint should scope its lock at service + environment + infrastructure level, so that deployments to distinct infrastructure definitions within the same environment can proceed in parallel as configured. Steps to reproduce: Configure a pipeline with a multi-infrastructure deployment stage with parallel execution enabled Use two or more infrastructure definitions scoped to the same environment Trigger a deployment and observe that one infra's stage is queued behind the other at the Resource Constraint step Impact: This directly undermines the parallel execution setting in multi-infrastructure deployments and adds unnecessary deployment time, particularly in environments with multiple target hosts or infra definitions.

Current state we can provide suggested values for Semantic Versions and Strings when setting up a custom attribute in FME. e.g. "test", "testing" -- "1.0.0", "1.1.0", "2.0.0" will appear as suggested matchers when using that attribute on a flag Desired state would be that we have that option for DateTimes e.g. 3/12/2026, 12/31/2025, will appear as suggested matchers when using that attribute on a flag

In parent build history the user is not able to see the Git hash in the failed pipeline. The parent dashboard is directing the user to check the child pipeline for git hash. This only happens for the failed pipeline, for the successful pipeline the parent shows the proper git hash

Request: Support STO verification for container images that were signed outside of STO. Problem: Today, STO verification only works if the image was signed by STO. Many teams already sign images using other tools in their CI/CD pipelines. This requirement prevents them from using STO verification unless they change their existing signing process. Proposed Solution: Allow STO verification to validate images signed by external signing tools or trusted authorities, instead of requiring STO to perform the signing.

It would be helpful if a Step's (or stage's) matrix values could be access by a subsequent step/stage in the pipeline. (Perhaps: <+pipeline.stages.MyStage.spec.execution.steps.MyStep.Matrix...>) This would allow the next step (eg MyNextStep) to dynamically interrogate specific instances of the matrix step. For example if MyStep has a matrix of [alpha,bravo,charlie], resulting in executed steps of MyStep_alpha, MyStep_bravo, and MyStep_charlie, then currently MyNextStep needs to either be hardcoded to read values from these steps or perform complex parsing of the entire pipeline file. However with this feature MyNextStep could read the matrix value directly.

In Harness on the search navigation on the left hand side bar where you change projects/orgs it would be handy if you can right click on a project/org and open in a new tab/window. Currently the browser (Chrome & Edge I tried) doesn’t allow you to.

Pearsons ELL would like to request a Spill-over/carry-over metric to track committed work carried over to the next sprint. This is currently not available in SEI 2.0 or 1.0

The Issue In SEI 1.0, Pearson ELL leverages a specific filter to track changes across Stories, Tasks, and Spikes. Currently, this filtering capability is not available in SEI 2.0. The Impact Because we cannot isolate these specific work items in the new 2.0 experience, as such the Lead Time to Change (LTTC) chart is not a good representation. The data in 2.0 is currently pulling in non-comparable metrics, making it difficult to maintain an "apples-to-apples" comparison with our legacy 1.0 reporting.

USCIS is requesting for Harness SMP to also support Istio in Ambient Mode to enable lighter, more efficient service mesh deployments in EKS. Our understanding is that currently Harness SMP is only supporting Istio Envoy Gateway. Istio in Ambient Mode eliminates the need for sidecar proxies, reducing resource consumption and operational complexity. Adopting Istio in Ambient Mode also aligns with industry trends and enhances Harness’s value for EKS users. Enabling Istio in Ambient Mode will help USCIS and other Harness SMP customers optimize their cloud infrastructure and accelerate application development. It is our understanding that Matt Moran from Harness already opened a Harness internal ticket number CXE-2231 related to this USCIS request. USCIS Git Issue Ticket # for this request is 198