Feature Requests

Although configuring multiple helm charts (manifests) on a native helm service is supported as per https://developer.harness.io/docs/continuous-delivery/deploy-srv-diff-platforms/helm/native-helm-quickstart/#using-multiple-helm-charts-in-a-single-harness-service , During the execution a primary manifest has to be selected. This might benefit if the charts are different for different environments. manifestConfigurations: primaryManifestRef: <+input> However, deploying multiple helm charts when deploying a service isn't possible (The error NativeHelm deployment support only one manifest of one of types: HelmChart is noticed if the above block is removed). For instance, deploying a monitoring stack that contains multiple tools such as prometheus, grafana etc will require separate charts for the tools to be deployed. This request is for having an option to deploy all the charts from the manifest in the same service(monitoring stack) instead of having the charts deploy through separate services.

Right now we can store services, pipelines, and inputsets in Git, which makes it a lot easier to manage and provides some version control. Triggers don't support this, is this something coming in the future?

We are having a feature to configure email notifications for Harness Traditional CD Pipelines, whereas Harness is not having a feature to provide the email notifications for Harness ArgoCD GitOps pipeline. We need this feature desparately.

The Raisin team faced challenges using Harness Blueprints for blue-green deployments with Helm, primarily due to limited support for Helm hooks and post-deployment jobs. To meet their requirements, they had to implement a custom solution. Improving Blueprint flexibility especially around Helm-specific lifecycle hooks would help teams adopt native Harness solutions for advanced deployment strategies.

As commented in several meetings with Harness. We currently have a problem with the way Harness uses the connectors when making changes to Git Experience resources. The permissions that users have in GitHub avoid the commit directly to main branches, making mandatory the use of Pull Requests to commit changes to the default branch. However, the connector configured in Harness uses a GitHub App with permissions to commit to main branches (necessary for Git Experience). That is making possible that an user who changes resources from Harness UI can commit those changes directly to the main branch. In GitHub it appears like the user is pushing the commit, but the Harness impersonates as the user doing the change and pushes the change with its credentials (see attached). This request is to add the feature to use the permissions from GitHub when doing changes from Harness, instead of using the connector.

I would like for multiple groups of people to be able to review in their own time without blocking each other. Currently, we could specify multiple user groups in HarnessApproval spec, but it doesn't actually require each one of the group to approve. Minimum count behavior is also not properly documented. Setting it to be bigger than one would allow multiple person from the same user groups to approve, without actually requiring the other group.

Currently, in the File Upload step, users are required to wait for a timeout (e.g., 5 minutes) if they don't need to upload a file. It would be much more efficient if there were an option to allow users to manually skip this step, enabling them to continue to the next stage in the pipeline without having to wait for the timeout. This enhancement would provide greater flexibility, allowing users to bypass unnecessary steps and keep the pipeline execution smoother. The goal is to add a "Skip Step" button alongside the "Upload Files" option, giving users better control over the process.

We'd like the ability to fail the pipeline if it is unable to fetch the codebase expressions. We are using <+codebase.commitSha> and if this is empty or null, it causes issues with our entire pipeline. We've noticed that our pipeline doesn't fail until it gets to the Deploy stages which makes it hard for us to understand why this has failed and cleaning up the Build stages from the null expressions is also difficult.

When using a custom trigger, it is possible to bypass the validation set for a step variable. For example, if you have a step variable set up with the following input validation: <+input>.regex(^[a-z0-9-]{0,55}$), the validation works as expected when the pipeline is executed manually. However, when the pipeline is triggered via a custom trigger, it can bypass this validation, allowing input values that do not conform to the defined regex pattern. The pipeline will run without enforcing the validation, and the input value provided by the custom trigger can fail to meet the specified input validation.

Currently, we do not have a field to fetch the commit branch in custom dashboards for builds and repositories. Can we please add this functionality to enable fetching the commit branch for pipelines? This would greatly enhance visibility and tracking in our dashboards.