Feature Requests

For the CCM connector, when a connector is created for the first time and no cost reports are available at the source, we should display a warning message indicating that: “The connector is healthy, but no cost data is currently available at the source. Once cost data becomes available, it will automatically start reflecting for analysis in perspectives.” This will help users understand that the connector setup is valid, but the absence of data is due to missing reports at the source rather than an issue with the connector itself.

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

Customers lack clear visibility into GCP Committed Use Discounts (CUDs) and Sustained Use Discounts (SUDs), leading to unused commitments and missed savings. This feature introduces a GCP-focused Explore in Harness CCM with insights into Compute Engine, Cloud SQL, BigQuery, and Memorystore costs — showing CUD coverage, utilization, SUD impact, and optimization opportunities. Users can quickly identify underutilized commitments, discover new savings, and compare current vs. optimized states with fast, drill-down visualizations.

Harness currently does not provide a way to specify Cloud Provider connectors (e.g., GCP Artifact Registry, AWS ECR, Azure ACR) as base connectors for Docker build steps. The only supported option today is the Docker Registry connector. Problem Statement Our organization’s container builds require pulling base images from multiple cloud registries. Since Harness does not allow Cloud Provider connectors to be used as base connectors, this has become a blocker for all teams across the organization. Impact Organization-wide blocker for container builds and deployments. Prevents us from using Harness native pipelines to build and deploy images. Hinders adoption and standardization of Harness across teams. Requested Enhancement Enable Cloud Provider connectors (e.g., Artifact Registry, ECR, ACR) to be used as base connectors in Docker build steps. This capability is essential for enterprise adoption and for teams to continue building and deploying images securely and consistently using Harness. It would also be hi

Tests tab count needs a fix (User should not be looking into the console and do the math to understand what is executed)

In order to support BitBucket authentication for user accounts and the upcoming deprecation of App Passwords, we would like Harness to support API token authentication as advised by Bitbucket: https://www.atlassian.com/blog/bitbucket/bitbucket-cloud-transitions-to-api-tokens-enhancing-security-with-app-password-deprecation Please provide us this new feature so that we can continue to utilize our connectors.

Retro ticket for request made in Late July/ Early August meeting with iHerb/Harness on IaCM, showing iherb's evaluation. We discuessed with Uri Scheiner that we need a workspace locking mechanism that will pause/suspend workspaces with pending approvals, from running more than plans for new runs. This will avoid situations where state mismatch could roll back changes. Eg; Change 1 applies a code version and is pending an approved change window to complete. In the mean time, change 2 applies a different version of other code referenced in the same terraform/tofu workspace, and is applied completely. If change 1 is continued after change 2, the updated from change 2 will be reverted as the state does not match.

Similar to the CD module user would like to have the Approval as a CI step.

Hi Harness Team, As we adopt Harness for CI/CD, we’re facing challenges with unit test coverage reports (JaCoCo, Istanbul, Cobertura, etc.). Today, making these reports viewable requires either making storage buckets public (a security risk) or building custom hosting solutions, which reduces developer experience and creates overhead for every team. We’d greatly benefit from a native Harness capability to attach and serve static artifacts (HTML/CSS/JS) securely within the pipeline UI, governed by RBAC. This would remove the need for workarounds and provide developers with direct, consistent access to coverage results. Is this functionality planned, or is there a recommended Harness-native pattern we should follow?