Feature Requests

Provide ability to validate the inputs to a workflow form beyond the standard single value or regex validations. Something along the lines of the ability to call an external function or API to carry out a check and return a value to confirm allowed value, or writing an inline function to execute and carry out a validation. An example scenario could be checking for existing code repo name when providing a name for a new code repo to be created rather than having this fail at some point later during the pipeline execution.

To reduce load on developer teams, our product team would like to maintain Kubernetes workloads through our Centralized ECS Delegate. Currently, users that deploy into EKS have to create and maintain their own EKS delegates. This has been a pain point for our users and adds complexity to onboarding as well as overhead on the development teams.

Please provide an option to configure the Baseline so that it is set only on the first successful scan of the master/main branch. Currently, the Baseline is updated after every successful scan on master/main, which causes net new vulnerabilities to disappear from subsequent scans since the Baseline keeps shifting. As a result, builds are not being gated by new vulnerabilities, because each new successful scan resets the Baseline and removes the visibility of net new issues in following builds. This dynamic updating prevents us from blocking builds based on newly introduced vulnerabilities, which is a key requirement for our process.

Changes made directly in Github do not go through any validation. Harness only validates pipeline changes done through Harness UI. If we are to make a change to 300+ pipelines via Github, there is no way to run this validation right now. Request is to expose Harness validation API or build a feature where users can easily validate their feature branches.

Intelliflo requires a more basic version of auto-stopping. Today, the auto-stopping is based on the service or namespace. This is too granular for the core team's needs. They would like it to be on a cluster level or multiple namespaces.

Pipelines triggered by triggers do not consistently surface the release tag in the execution overview. This makes it difficult to trace executions back to specific releases. There should be a consistent way to capture and display the release tag as part of the pipeline metadata when triggered via any trigger type. This would improve visibility and traceability across pipeline executions.

Hello Team. Although some of the stats from the STO Overview page are available in the standard STO dashboards, the full view as seen previously is not available. Please make those stats and format available in a new dashboard so we can get that information again. It was useful for us.

need to merge two services into single service using override values to differentiate them Our automation expects single service here need some guidance here

Segregation of CI and CD pipelines for easy maintenance and better readability. Folder structure for maintaining CI and CD pipelines based on services or tech stack.

I'm using the code coverage policy mentioned in https://developer.harness.io/docs/security-testing-orchestration/policies/create-opa-policies#block-the-pipeline-based-on-the-code-coverage-results , in one of my pipelines. But instead of the hardcoded threshold value for comparison, I would like to use a pipeline variable. I understand that this feature is currently not available in harness. Can you please help. Regards, Janish