Share your feedback...
Allow users to Delete Runner Resources using the UI
This is currently possible using the CircleCI CLI ( https://support.circleci.com/hc/en-us/articles/15418352844187-How-to-delete-a-Self-Hosted-Runner-Resource-Class ) This request is to enable parity of the same functionality in the Runner UI
Runner UI - Easier to scroll through list of Runners
For teams using a number of runners, the UI list can be tedious to scroll through. The ask is to figure out how to make the Runner UI easier to scroll through.
Locally hosted task agent
It would be great if the team could implement a way where you can download the task agent and put it locally against your Cluster for easier/faster downloads.
Hard limit for Runner execution
If a container runner pod fails to launch, or remains unscheduled, cancel the job
Configure container runner pod in config file
Allow resources to be configured from within a CircleCI config file rather than in the values.yml file to allow for more job-specific resource configuration
Resources Insights for Runner
Similar to running jobs using CircleCI's machines, it would be ideal to have the same for Runners using our own architecture. The CPU and RAM columns are blank for some jobs in our insights dashboard, particularly the self-hosted runner jobs.
Higher Order Runner Labels
Currently resource class can be used to group runners, but if a new, updated resource class needs to be introduced config changes need to be made. This is exacerbated when working in a multi-org ecosystem. If runners had a higher order of grouping that could be called in the config, it would eliminate the need for config changes when a resource class is changed out for a new one.
Provide metrics to Prometheus from Container Runner
In some cases, it may be good to surface Container Runner metrics to Prometheus. Such as Task count, Task limit, error logs, etc.
Allow an ENTRYPOINT override on Container Runner
Currently, Container Runner does not allow the use of ENTRYPOINT override for your Docker Container due to a limitation with permissions. It would be great to support this feature and document what permissions are needed if someone is not using the default permissions in their cluster.