Feature Requests

We have security enforcement on our Openshift platform that refuse the image with user ContainerAdministrator. We need a rootless (UserContainer) for the plugins/cache image. This will provide a cache for DotNet 4.8 (which must be compiled under Windows) and gain developer buy-in through a better development experience.

On the Execution History tab of a pipeline, always keep and display at least one item, even if there are none found in the last 30 days (or whatever the retention period is). For pipelines that run infrequently, it's alarming and inconvenient to see "No executions found" there. Alternatively, allow the default display period to be configured, at least up until the full retention period where summary data still exists.

In veracode scan or Sonar scan, once the scan is completed the result is available in the output in different severity levels eg: high, low, etc Similar to that feature, as a pipeline developer, I want to enable the test intelligence result output to be available in the execution output so that I can refer the facts not limited to - how many test cases executed? how many failed? what are test names? etc Benefits: Based on the output results placeholders, we can design the granularity to implement the quality gate or have a policy implmented.

provide support to restore cache dependency automatically using npm install for node without using custom path Currently It is supporting for yarn install with default path (.yarn) So If you can also provide support for npm install with default path(node_modules) then It will be really helpful for us.

For test execution summary visualization in dashboards, we need Build Duration as a field.

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

When using the “Save and Restore Cache from S3” step to cache Gradle dependencies, restored files and directories are assigned new timestamps rather than preserving the original inode metadata (e.g., access/modification times). This makes it impossible for Gradle to perform cache pruning using built-in mechanisms like: removeUnusedEntriesAfterDays in DirectoryBuildCache Directory cleanup via atime with find gradle_user_home cache maintenance options As a result, the cache grows rapidly over time—Eugene Kossyak reported growth from 2.8GB to over 5GB within a week—because obsolete or unused dependencies can't be cleaned up effectively. This significantly undermines the value of caching, and in some cases, leads to slower builds than re-downloading dependencies from scratch. Customer Impact: This affects customers relying on Gradle’s caching mechanisms to optimize CI performance. Without proper cache pruning, builds slow down, and cache storage grows unsustainably. The current behavior also breaks alignment with Gradle's documented expectations for cache lifecycle management. Workaround Attempted: Setting Override Cache = false (intentional, to avoid snowballing caches) Manual cleanup using find commands (ineffective due to lost inode metadata) Attempted Gradle-native cleanup options (non-functional for same reason) Request: Enhance the drone-cache plugin (underlying the “Save and Restore Cache from S3” step) to preserve inode metadata during archive and restore operations—especially timestamps—so that file-level pruning can function as intended

Context: As part of our platform engineering practices, we manage Harness templates using a versioning strategy. Currently, each template version is referenced explicitly by its version number. However, this approach requires application teams to manually update their YAML configurations every time a new version is released—even when the changes are backward-compatible or limited to internal script logic. Proposed Enhancement: Introduce support for static version tags—such as latest or stable—in Harness template versioning. These tags would act as pointers to specific numbered versions in the background, similar to how Docker image tags work. How It Would Work: Platform teams define and maintain static tags like latest or stable. These tags internally map to specific numbered versions (e.g., v1.3.2). Application teams reference templates using these static tags in their YAML files. When a new version is released, platform teams update the tag mapping—no changes required from application teams unless there are breaking changes. Benefits: Centralized version control: Platform teams can manage which version is considered latest or stable without requiring downstream teams to update their configurations. Reduced maintenance overhead: Application teams only need to update their YAML files when there are changes in input/output variables or breaking changes. Improved agility: Enables faster rollout of non-breaking updates (e.g., script optimizations, internal logic changes) without coordination delays. Alignment with industry practices: Mirrors the Docker image tagging model, which is widely understood and adopted. Use Case Example: A template deploy-service has versions v1.0.0, v1.1.0, and v1.2.0. The platform team tags v1.2.0 as stable. Application teams reference deploy-service:stable in their YAML. When v1.3.0 is released and validated, the platform team updates the stable tag to point to v1.3.0. Request Summary: Please consider adding support for static, user-defined tags (e.g., latest, stable) in Harness template versioning. This would significantly streamline template management and improve the developer experience across teams.

Currently the default images API https://app.harness.io/gateway/ci/execution-config/get-default-config?accountIdentifier=<$YOUR_HARNESS_ACCOUNT_ID>&infra=K8 " does not list all the plugin images. Including these plugin images to the get-default-config API shall help in the following Identify the latest working plugin image as going by the image repository, there might be images that might be released but are not guaranteed to work. Having the images provided in the default API shall provide an idea of what latest version of the plugin works instead of users trying and testing multiple image versions In many instances, there are automations setup in place to pull the images from Harness public repositories to internal repositories by referring the image versions under get-default-config API. Including plugins/artifact-metadata-publisher shall help in automatic push of plugins/artifact-metadata-publisher images when a new version is available This request is for plugins/artifact-metadata-publisher but shall benefit if other plugins are included as well.

For build executions, we would like to be able to view actual pod usage metrics (CPU, memory, and disk) within the Harness UI. Currently, the only way to view these metrics is by viewing logs within our clusters.