Feature Requests

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.

As a part of our effort to standardize processes, we want to be able to store our Custom Secrets Template Scripts as FileStore. This was shown as possible via the UI, but was later flagged as not possible, as the scripts need to be stored inline

The banner on harness UI comes by default with dismissible option. Since one of our banner is highly important. There shouldn't be any way that it can get dismissed by user

We are using Takeda.io for our EKS deployment. It would help us if we have our CI too on this platform instead of using GitHub Actions to push to JFrog Repository.

Hi Team, We have a requirement to invoke pipeline in another project. We want to do it in either of the way, Either want to invoke the pipeline stages from the another project pipeline Either Want to invoke the pipeline as stages in current project and want to set some condition to execute only one stage at a time. But harness is throwing, "nested pipeline cannot be used" error.

Customer: Dish context: https://developer.harness.io/docs/platform/delegates/install-delegates/delegate-upgrades-and-expiration/#override-delegate-image-version Current documented behaviour. At max, there can only be two override entries corresponding to a combination of query params: accountIdentifier, orgIdentifier (if present), and projectIdentifier(if present): one with tags and one without tags. If the same combination of parameters is used with a different value of tags or delegateTag, then the existing entry will get updated. Customer is requesting for the ability to have multiple override entries (not just two) as it becomes easier to manager multiple delegate groups with different versions.

Hi Harness Team, I’m currently working on a project with a growing number of CI/CD pipelines, and managing them within a single flat view is becoming increasingly difficult. It would be extremely helpful to have the ability to organize pipelines into folders or categories within a project. This feature would allow us to: Group pipelines by microservice, environment, or team Improve visibility and navigation Reduce clutter in the pipeline dashboard Align better with enterprise-scale CI/CD practices Could you please let me know if this feature is on the roadmap or if there’s a workaround available? If not, I’d like to formally request it as a feature enhancement. Thanks for your support! Best regards, Piyush Kumar Configuration Release Analyst Specialist

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.

The current behaviour of GitExperience Webhooks with GitHub does not provide a very developer experience for anything other that simple scenarios. The webhook currently takes events from GitHub (pull requests), and based on the diff of the commit, it will: Create a new Harness object if there is a new file in the diff Update a Harness object if there is a modified file in the diff Delete a Harness object if there a removed file in the diff There are a number of problems with this behaviour, including but not limited to: Deletion of a file and creation of an almost similar file in the same commit shows up in the diff as an update rather than a deleted file and a new file. Deletion of a file does not fully remove the object in the Harness UI (the support ticket I raised states this is because the webhook doesn't update the Harness database). Updating the name or identifier of an existing Harness object leaves the object in a stale state where the display name and identifier show in the UI under the old name but the YAML shows the updated values (this again I assume to be a database update issue) Updating files whose 'new object' event errored for any reason (an example would be an invalid identifier when the file is first created) fails to create the object as it treated as an update to an object that doesn't exist; the solution to this involves a change to delete the file(s) then a subsequent change to re-add them back in and is a painful experience when changes require approval. Creating and then updating a second file with the same content (critically the same identifier) as an existing Harness object treats this as an update to the existing object. The expectation for the behaviour is that the webhook should treat the GitHub repository as the source of truth for all objects, and should compare the current set of tracked files with the inventory of the Harness project. It should create its own diff based on that context, and perform the appropriate action(s) to ensure that the Harness project's objects match those in the GitHub repository (errors excluded). Critically, it should also reflect changes in the database where required to keep this in line.

For test execution summary visualization in dashboards, we need Build Duration as a field.