Feature Requests

We would like to extend the data retention period for the cd module in the NextGen platform to 12 months. We currently have the same period in the FirstGen platform.

We are using several templates at the org level (steps and pipelines). Projects are consuming the pipeline templates and often need to be reconciled when variables or other elements in templates change. Is there a way to programatically (API endpoint, Terraform) reconcile pipelines after templates have been updated. Right now the only way I can see doing this is through the UI and manually clicking through pipelines to see which needs to be reconciled. This is adding a lot more time to using templates. Why can't the pipelines that are calling the templates just render the template at run time? I am doing a very similar approach on GitHub actions and never need to inform my upstream workflows to update themselves because a template changed. On checkout, my actions use the template ref provided. I'm guessing because the templates do not live in an SCM system, that the Harness pipeline that is referencing the template needs to store a cached copy of the template? The whole reconcile pipelines does not make a lot of sense to me. I want the template to drive what is happening in the pipeline and not have to constantly make sure the "caller" pipeline is caching the template...or whatever is happening under the hood. I can understand locking a pipeline to a known good template, but isn't that why there are template versions? Which is a whole different topic.

Currently if we try to modify pipelines and choosing branches from the dropdown, it lists only 20/30 branches depending on the git provider. Anything above is not even searchable. The expectation is to return the first X results matching search string

Please can improvements be made when using the specify infrastructure field during deployments. Currently the list is not sorted alphabetically can this be ordered in this may to make it easier to search. A further request would be to make this field searchable, giving the developer the ability to start typing and results come back, for example if a dev would type "sma" the drop down would filter alphabetically smapiv1 smapiv2 and so on and so on.

We want the ability to deploy applications and execute jobs on Google Cloud Run. https://cloud.google.com/run/docs/overview/what-is-cloud-run

There are currently step and stage level failure strategies. I'd like the ability to define a pipeline failure strategy, and execute a rollback for deployment types that support it. This should work for multi-service and multi environment deployments.

Description: Helm chart dependencies are not supported in Git source repositories (Harness Source Repo Providers). Motivation: In order to use helm library, which we developed internally, as part of workflow we need to execute "helm dependescies build" which is currently not available in Harness. How is this currently done: Terribly wrong: we have to commit helm library tarball into our git repository as there's no other way to execute it even as shell step. Impact: No binaries should exist in Git VCS but using Harness in this use case is not possible otherwise. This is serious limitation for a widely adopted tool. Solution: Should be trivial command sitting next to existing two "fetch" and "pull" or simply a checkbox "Resolve dependencies". The first looks more consistent with what's currently implemented.

Need an option to upload files (images, docs) from the user local machine as a runtime input to steps. One of the use case is upload screenshots of manual/user acceptance testing that will be uploaded as an evidence along with the Artifactory.

There's support for AWS Lambda/Google Cloud Functions and even Azure Web Apps. Any chance there will eventually be Azure Functions support?

We have a need to handle release orchestration, or orchestration of multiple services during a production deployment. While we wait on that enhancement (sounds like soonest it will be developed is Q1), we can get most of what we need by giving developers access to create and modify input sets. The issue is that granting developers the access to do what they need to do also gives them access to modify pipelines. We want to restrict access to that due to DSOD considerations. With that in mind, is it possible to get a separate permission for creation and modification of input sets? By implementing this it will help us to ramp up on adoption.