Feature Requests

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

Feature request as suggest by Harness team to enable system level error retry mechanism for the below failures : - Pod eviction Failure to connect to addon client Connectivity errors between delegate and ci lite engine ref : https://support.harness.io/hc/en-us/requests/72479?page=1

I Would like to access service variables, and repository name from the service directly when doing CI stages Service would be the only entity for CI/CD

When a CI stage is present in a pipeline and it gets triggered by a trigger of type ARTIFACT the pipeline throws this error Invalid request: CI stage cannot be triggered by trigger of type: ARTIFACT

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

Feature request: Need the ability to dynamically set environment variables for a step, or parse from JSON. This will enable more flexible use of in-stage builders and lessen inputs only needed for certain use cases.

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.

Upgrade MacOS image Xcode 16.3 for CI builds

Is there a way to freeze (prevent execution) of custom stages and CI stages as part of a freeze window? We have many pipelines which leverage these custom stages as part of deployments. Additionally, we sometimes need to freeze builds.

We would like to have the default container resources (Limit Memory – 500Mi & Limit CPU – 400m) removed so that there would be no limit set at all. Either removing it from your side works or even preferrable to give this control to us to set / remove the default limits, especially when we're relying on self-hosted build infra i.e in our case our on-prem k8s cluster. This helps us address the resource issues across the account, instead of customizing the resources specific to individual pipelines/steps which would be an overhead and also not reliable. We understand there is a FF to increase the defaults but we're not looking at that option, we're looking to have the defaults removed or the control be given to us. When we're leveraging our self-hosted build infra, we expect to have that control.