Feature Requests

The option "Auto-Reject previous deployments paused in this step on approval" works only within the context of a pipeline execution where it just checks and rejects old executions waiting for approval when their latest step is approved. It does not perform checks on the environment(or any input) configured on the stage. This is currently by design. Consider a scenario where the environment is passed as an input to the pipeline when executing it. * There is an execution started with environment "Environment-1 " as the input and this was waiting for approval. * There was another pipeline that was started after the above execution and it was started with the environment "Environment-2". Once the execution with environment Environment-2 is approved, the previous execution with Environment-1 shall be rejected . It appears that when "Auto-Reject previous deployments" is enabled, the inputs passed to the execution are not compared. However, it checks to the service as long as the service is within a CD stage. The request here is to include and compare the inputs passed to a pipeline before choosing to reject the previous execution. That way pipelines only with the identical inputs are rejected when an approval is made on the latest execution.

Currently the master url specified in kubernetes connector , if we are using the option specify master url and credential, is in plain text. This feature request is to have the ability for specifying the master url as a secret as it would be a secure approach of using the Master URL for the Kubernetes Connector.

When a CI stage is present in a pipeline and it gets triggered by a trigger of type ARTIFACT the pipeline throws this error Invalid request: CI stage cannot be triggered by trigger of type: ARTIFACT

We maintain GCP Terraform state files in GCS buckets. We use Terraform Open Source. We are looking for GCP deployments to run through Harness pipelines, but we do not find an option to add GCP connector at Custom stage Terraform Plan/Apply/Destroy/Rollback steps.

Currently, evaluation of OPA policies on terraform cloud side is not supported in harness terraform cloud step. Please add support for it.

While troubleshooting a Git connector test failure, the error messaged seen in UI displayed a generic error message.we later grabbed the delegate logs to determine the true nature of the error, in this case it happened to be a SSH private key issue. This feature request is to be able to see more detailed connector test verification related error messages in the UI. This behavior was observed specifically on the Git connector, but may apply to other connectors in general.

We would like to run CV for serverless canary deployments using AWS SAM: https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/automating-updates-to-serverless-apps.html These deployments happen in the same process as the rolling deployment, and AWS has the ability to perform basic CloudWatch Alarm checks as well as basic traffic shifting between versions of the lambda.

Problem: In Harness pipelines, when the "Auto Approval" feature is enabled within the Approval stage, the "Approvers Count" and "Approvers Details" fields remain mandatory. This creates unnecessary overhead and forces users to provide placeholder values when they intend to bypass manual approval entirely. Desired Behavior: When "Auto Approval" is selected for an Approval stage, the "Approvers Count" and "Approvers Details" fields should either: Automatically be populated with default values (e.g., "0" for the count and an empty list for the details), or Be made optional, allowing users to avoid configuring irrelevant fields for auto-approval scenarios. This would streamline the pipeline configuration process and reduce unnecessary steps when auto-approval is enabled.

We want to generate a YAML path regex that will disallow users from uploading resources into the wrong directory on our repository. For example, something like ^/configs/services/.*

Currently the step logs are getting truncated when it is exceeding a size of 5MB. The workaround suggested to save the script output to a file and make it available in an object store is not helpful and having issues using this workaround in the run test step. We should be able to see the full step logs even if it is exceeding the sizes of 5MB