Feature Requests

Problem Currently, when a pipeline needs to be intentionally halted after a successful gate-check or decision stage (e.g., "Promotion not required at this time"), the only method to discontinue execution is to set the stage status to 'Aborted'. This creates a significant reporting issue, as 'Aborted' pipelines are universally categorized as 'Failures' in all reporting dashboards. This misrepresents work that was technically successful but intentionally terminated, skewing our overall success metrics for the larger team. Proposed Solution We request a new pipeline failure strategy or execution status, such as 'Success and Stop Execution' or 'Complete - No Further Action'. This status must: Allow the pipeline to terminate immediately. Ensure the pipeline run is categorized as 'Success' or 'Complete' in all reporting metrics. Why Not Use Workarounds? The current alternative—using conditional wrappers on every subsequent stage—is inefficient, requires extensive refactoring of all existing pipelines, and is difficult to maintain when new stages are added.

We received confirmation from the Harness team that currently there is no native support for executing STO scans directly on ARM infrastructure without relying on ingestion mode. As of now, the workaround involves running the scan in a separate run step, generating the scan file, and then using the STO step in ingestion mode to feed the results. https://developer.harness.io/docs/security-testing-orchestration/whats-supported/infrastructure/ We would like to request an enhancement to support direct STO scan execution on ARM infrastructure, eliminating the need for this multi-step workaround. This would streamline the process and improve integration efficiency for ARM-based environments.

see https://support.harness.io/hc/en-us/requests/95145 I have a use case where I need to build a docker image in both our non-prod and production environments. I use an S3 bucket configured in the default settings menu of our Harness account that lives in our central non-prod AWS account. I cannot use DLC for the build in our production environment because we don't have cross-environment connectivity available. I'd like to be able to configure multiple caching locations and choose which to use based on the delegate that is running the build.

We require a control at account level to restrict users from copying specific 'Account level' templates (instead only allow 'Use Template' option') in order to ensure no other user from a project can attempt to modify the pipeline by changing the defined standard steps used in account level template.

JUnit is changing to a new reporting format that is supposedly language agnostic, can harness please add support for open test formatted reports in it's test reports as well? https://github.com/ota4j-team/open-test-reporting

Currently we are running API tests post deployment and we are posting the test results in K6 so it is visible in the tests tab in the pipeline. This feature to publish test results is available only in build stage, hence we are using a build stage post deployment. if there is an API available to publish test results within harness than we can use it instead to publish tests results back to the pipeline and users can view the test results under tests tab in the pipeline

We have a pipeline where we are generating some files in one stage 1 and that has to be accessed in the next stage 2 but we don't have an option for it to share files across stages. A workspace like concept is missing, if it is available then we can place the files in that is generated in one stage and access the same file in next stage.

Currently in our CICD pipeline, we are running API test post deployment. We don't have access to the checkout code post deployment or post the CI build stage. We don't want to check out the code again to run the test files. It will be useful if the check out code is available across the stages/thought out the pipeline.

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.

In pipeline few stages like CI testing, STage testing ADA testing generates results in xml format. Is there a way we can integrate these to harness data and generate harness dashboards ?