Feature Requests

Currently the expression suggestion does not show up in the email body. However, the expression resolution works fine and the YAML view still provides the suggestion when the body content is edited. Providing the suggestions for email body shall provide better user experience.

Currently either from Execution History or over of a specific service, we can only look through deployments for specific Environments. We would like to see the infrastructures in there. We have multiple infras in each environment and it would be really helpful to see this information without having to dig through each execution.

If you have a Harness Expression in a Shell Script that's been commented out, Harness will still try and evaluate it which can cause unexpected failures. We'd like for the comments to not evaluate any expressions.

If a pipeline is retried, the results panes, (unit tests, artifacts, security tests, etc), are wiped. This makes sense if the stage that produces these reports is retried. If the stage that produced the report has not been retried in this execution, its report should carry over to that retry. This can help teams use those reports without needing to dig through execution retries.

We need a way to be able to support volume tagging in our pool.yml. We had to disable SCP on that Amazon account to bypass this in the interim. But we'd like to be able to enable that once again.

Harness currently supports variable resolution (e.g., <+ env.name >) in Kustomize patch files only when those patches are explicitly defined through the Harness UI under Service Manifests → Kustomize Patches. However, if patches are defined directly in the kustomization.yaml using patchesStrategicMerge, Harness variables are not rendered, which can result in deployment failures due to unresolved values. Use Case: Each environment (dev, QA, etc.) has its own overlay and unique patch files. Patch files may change across releases depending on what needs to be customized for each environment. Managing the patch file paths from the Harness UI adds friction and introduces risk (e.g., pipeline failure if a patch file doesn’t exist for a given release). Developers are more comfortable managing kustomization.yaml directly, as part of GitOps workflows. Having to switch between Git and the Harness UI to keep patches in sync can be error-prone and less scalable. Proposed Enhancement: Allow users to specify patches directly in kustomization.yaml using the standard Kustomize format: ================ bases: - ../../base resources: - xyz.yaml patchesStrategicMerge: - abc.yaml ================ Enable Harness variable resolution (e.g., <+ env.name >, <+pipeline.variables.*>) within these patch files without requiring them to be added as separate Kustomize Patch manifests in the Harness UI. This would provide a more Git-native experience and allow flexible, environment-specific patch management without additional UI overhead.

Containerised step group is not currently publishing the test report to the the execution UI even though the report path is correctly configured in the run step. Can we have this feature enabled on the containerised step group in the same way we can do this in CI run step?

Currently we need to consider the following points for executing remote chained pipelines: A chained pipeline is fetched from the default branch when the parent pipeline is defined inline, and the chained pipeline is defined remotely. When the parent pipeline is defined remotely, and the chained pipeline is defined inline, the parent pipeline is fetched from the corresponding branch, and the chained pipeline is fetched inline. When both the chained pipeline and the parent pipeline are defined remotely, but under the same repository, the chained pipeline should belong to the same branch as the parent pipeline. A chained pipeline is fetched from the default branch when both the parent and chained pipelines are defined remotely in separate repositories. This is irrespective of the branch of the parent pipeline.

I don't want the conditional execution of a pipeline to block a PR's ability to merge. See here for GHA docs: https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/using-conditions-to-control-job-execution Note: A job that is skipped will report its status as "Success". It will not prevent a pull request from merging, even if it is a required check.

We would like to propose an enhancement - the ability to scan the shell scripts used in the deployment steps for potentially destructive or risky commands such as rm, mv etc., This feature would help to analyze the scripts prior to execution, ideally during the approval step, and raise alert or warnings if such commands are detected. This allows teams to proactively assess potential impacts before approving a deployment, adding an extra layer of safety and visibility.