Feature Requests

Currently the CI stage is not sending the status check if the clone option is disabled. We need the CI stage to be sent status check irrespective of clone option is disabled or enabled

Currently, the Builds tab does not display the repository name associated with each build. Enhancement of the Builds tab to display the repository name associated with each build.

When a pipeline is re-run from a specific failed stage (such as the third stage) in execution, the Pull Request (PR) details are not displayed in Build overview page, as the CI stages (which include the PR details) are skipped during the re-run.

Currently, you can only change the Init Timeout field on a pipeline-by-pipeline basis. We would like to propose the following alternatives: * A Delegate-level setting where we can set the timeouts for every stage that uses said delegate, exposed as an environment variable. * A Project/Org/Account setting that sets the default Init Timeout value to a custom value.

Currently, each CI stage execution sends a separate status check. We need a single status check to be sent for the entire pipeline. Sending a custom status check from a run step is not feasible

Use Case: Right now, developers struggle to locate errors efficiently because test results are only visible within each individual pipeline. They have to manually click into each pipeline to diagnose issues, which is slowing them down. They are requesting a way to view test results in the parent pipeline when using chaining or a centralized dashboard to see all test results across nested pipelines.

Currently run as user option works only when the build is running in k8s cluster or in Harness cloud. We need to have this option work on local and VM build infra

Getting EC state=failed because of some steps in the pipeline are ignore failure. Is it possible to get the state =successful when other steps are ignore failure. By getting EC state as failed in the JIRA ticket under development the build is showing as failed even though the build is successful.

Error: The runs.using key in action.yml must be one of: [composite docker node12 node16], got node20

When leveraging the VM Build Farm we have to manage a pool.yml file. It would save us a lot of time and hassle to be able to mange this configuration directly in the Harness platform rather having to setup bespoke automation to manage this in git and update the machine where the drone runner s located.