Feature Requests

Customers using file-based triggers in Harness CI have observed that pipelines are being executed when a pull request is merged, even if the target directory (e.g., flutter/) was not directly modified in the merge commit itself. The root cause appears to be that GitHub includes all files changed in the source branch when a merge commit is created. Harness currently evaluates the changedFiles condition against this expanded list of files, causing the trigger to fire even if the actual merge did not change the target directory. Current Behavior: Triggers with a condition such as changedFiles: flutter/.* will run if those files were changed at any point in the source branch, even if the final merge commit doesn’t modify them. There is no built-in way to detect merge commits at the trigger level and apply different logic. Requested Enhancement: Introduce support for detecting and optionally ignoring merge commits in trigger evaluations. This could take the form of: A new trigger condition (e.g., isMergeCommit: false) The ability to evaluate only the files changed in the actual merge commit, not in the full history of the source branch A toggle or flag in the trigger UI/API to exclude changes from merge commits Workaround (Currently Required): Users must add a pipeline step to manually inspect the commit metadata and skip execution if it’s a merge commit: a non-ideal solution for CI/CD automation. Impact: This enhancement would prevent unnecessary pipeline runs, reduce execution overhead, and provide more precise control over file-based triggers, especially in monorepos and enterprise-scale workflows.

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.

Hi Team, Kindly enable the feature flag PIPE_BULK_RECONCILIATION_PHASE2 for the account "gomTD9umQGauvy9KLFG5WQ" as its required by the customer.

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.

In the Tests tab, is there functionality to view tests skipped by the test tool itself, and not Harness intelligence. So let's say in the command to run the function, someone sets a flag to ignore these specific suite of tests; is there a way for those skipped tests to be seen in the Tests tab? Thank you

Podspec overlay available in CI stage as mentioned in the below doc is missing in the containerized step group that can be added in the CD/custom stage. Please add the option to configure Podspec overlay in containerized step group https://developer.harness.io/docs/continuous-integration/use-ci/set-up-build-infrastructure/k8s-build-infrastructure/set-up-a-kubernetes-cluster-build-infrastructure/#topology-spread-constraints

We need the ability to set ephemeral storage limits on Kubernetes infrastructure for builds, stepGroups with infra, and container steps. Some tasks will use local ephemeral storage for scratch files and other temporary files. If the pods are scheduled on a node that has insufficient disk space for those files, the pod will be evicted which can be very disruptive depending on the process. The ability to set an ephemeral storage request (see Kubernetes docs here) will prevent pods from being scheduled on nodes that have insufficient disk space for the task. It will also prevent tasks that have the ephemeral storage request from being evicted first when disk pressure happens on the node.

Required support for S3 Encryption while uploading cache dependency packages to S3 Bucket for cache intelligence in CI pipeline. Please provide s3 encryption support when we upload any packages for dependency in s3 bucket. Currently we are getting error for encryption policy that we have enforced for our s3 bucket and after removing that policy we are able to push packages to S3 bucket.

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.

The kaniko project is no longer maintained, it is archived. See https://github.com/GoogleContainerTools/kaniko/issues/3348 Kaniko worked well for us since it does not require privileged mode. The other alternative supported by Harness - Buildx requires privileged mode. Are you planning to build Kaniko executor based on the Chainguard fork?