Feature Requests

I'd like to be able to track a few metrics surrounding the concurrent runner usage in Harness. Currently, we're using EC2 VMs, and I'd like to know if we're getting close to maxing out on our runner pool before we hit that threshold.

Requesting support for queuing a triggered build behind an in-progress build rather than aborting it.

Hi Team- We would like to request support for Test Intelligence in Step Templates. Currently, when attempting to create a Step Template from a working Test Intelligence step in a CI pipeline, we receive validation errors such as: body: is missing but it is required pipelineStatus: is missing but it is required -failureStrategies: is missing but it is required -when: object found, string expected -infrastructure: is missing but it is required

Currently, in the Harness CI stage, we do not have any option to configure Harness volume, currently the harness volume provision with no limits and we need ability to configure limits on it.

Hi Harness Support, Please enable Hosted Builds (Harness Cloud) for our account. Account: Temenos USA Organization: digital Project: ConversationalStudio Account Admin: Ragu Marimuthu We already have 2,000 Cloud Credits available but pipelines are failing with: "Hosted builds are not enabled for this account." Please enable this feature urgently as we have active deployments pending. Thank you

I would like to check whether it is possible to retrieve step logs from a pipeline using the Harness API as a direct output, instead of having to download them as log files. Having the logs returned as API output would make it much easier for us to parse and extract the required details programmatically. Currently, when logs are provided only as downloadable files, we need to download the ZIP, save it locally, extract it, locate the relevant log file, open it, and then parse the contents. This entire process has to be repeated for each pipeline, which is inefficient and time-consuming. Providing the step logs directly in the API response would significantly simplify automation and analysis on our side. For reference, you can also look at this related ticket: https://support.harness.io/hc/en-us/requests/103346

I would like to request an increase in the character limit for the tests tab, as the current 8,000-character limit is insufficient for storing detailed test results. Expanding this limit would greatly improve usability by allowing more comprehensive data to be saved and reviewed within the platform.

Currently VM Pool instances are tracked only in the VM Runner's in-memory state. If the Runner does not shut down gracefully (e.g. hardware failure, force termination, or ASG scale-in race conditions), the pool VMs become orphaned with no process to manage or terminate them. We have implemented startup scripts on the delegate that scan for and terminate orphaned pool instances on next boot, but this means orphans persist and incur cloud compute costs until the next delegate replacement. It also adds operational maintenance overhead that should not be the customer's responsibility. It would be a valuable enhancement to have the Runner persist pool state externally (e.g. tags, DynamoDB, or a local file) and reconcile on startup, or provide an official orphan detection and cleanup mechanism, so that pool VM lifecycle is reliably managed regardless of how the Runner terminates.

Currently AWS VM Pool configuration is stored in the VM Runner as a pool.yaml file. It would be a good enhancement to have this configurable via launch template. It gives the flexibility of performing hot updates to the Pool VM configuration without having to restart the VM Delegate/Runner which causes potential downtine.

Currently, the Docker Build and Push step does not support adding an expression for the entire Build Args field. You can set an expression in one of the argument's values but, not for the whole Build Args. For example, this works buildArgs: key: <+pipeline.variables.someValue> But, we'd like the ability to provide a comma separated list of key/value pairs to this field like this instead, bulidArgs: <+pipeline.variables.buildArgs>