Feature Requests

I need metrics related to CI pipeline executions, specifically visibility on execution durations down to individual stages or steps. This would greatly assist in monitoring for regressions or improvements when changes are made to pipelines. Ideally, these metrics should be exposed using the Prometheus metrics format.

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.

Many reports such as coverage, linters, unit tests from various languages, etc use proprietary HTML reports. Harness enables you to upload these reports as artifacts to S3 or similar, but it does not support HTML reports natively. I would like to see this feature make it to Harness similar to https://plugins.jenkins.io/htmlpublisher/ to support additional quality and build reports

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

Label the artifacts displayed in the artifacts tab for easier identification, instead of showing the full URL?

Currently, the Builds tab does not display the repository name associated with each build. Enhancement of the Builds tab to display the repository name associated with each build.

When a pipeline is re-run from a specific failed stage (such as the third stage) in execution, the Pull Request (PR) details are not displayed in Build overview page, as the CI stages (which include the PR details) are skipped during the re-run.

TransUnion team recently shifted from Jenkins to Harness Hosted builds for CI. They want to understand how the platform is scaling, how many pipelines are triggered at the same time, how many stages are running in parallel etc. Any concurrency metrics would be good to have.

When you set a stage variable, it automatically passes that down as an environment variable to all steps within that stage, even through templates, etc. This is disastrous for pipeline clarity and modularity because it's impossible to tell which stage vars are used for which steps and references to environment variables deep inside the code of a template might be relying on a stage-level variable at the pipeline level and there's no way to track that. Please provide a way to turn this off and only pass stage variables down to the environment variable level if they are specifically referenced using the envVariables system.

I want to use the AWS connector permission in S3 cache/restore step to access S3 however S3 cache/restore step is currently using the permission on the stage infrastructure connector. Expected behavior: When we specify an AWS connector in the S3 cache/restore step, we need to use the permission of AWS connector to access S3 rather than using the permissions defined in the stage infrastructure connector Observed behavior: In order to access S3 currently we don't use the permission of AWS connector configured in the S3 cache/restore step instead we use the permissions of stage infrastructure connector