Allow orgs to opt-in to allow OSS forked jobs on Runner
Creating this to track an ask from several OSS orgs. There is a desire to allow OSS fork jobs on their runner executors.
Add .ImageHash template for caching
I've run into situations with caching yarn dependencies where the validity of the cache depends on the docker image in which the install was run. It would be great if I could read/write cache per docker image hash
Make the requirement of the ClusterRole optional
I've been told that the reason why the container-agent chart need to deploy a ClusterRole is to automatically detect the CPU architecture of the node. Since the ClusterRole applies to the entire k8s cluster, there's some policy limitation in my org which makes deploying a ClusterRole complicated. It would be great if the chart allows specifying CPU architecture via a field in values.yaml so that we don't have to deploy the ClusterRole.
Lock certain Runners in an organization to specific user accounts
Value where you can specify which project is allowed to use this self-hosted runner. If other projects would like to use ex. DevOps Runners, pipeline will fail.
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.
Add the ability to deregister a runner
Currently a runner will be removed after a period of time. It would good to be able to remove a runner for example due to the machine the runner is on being taken down.
Ability to restrict runner usage
Would like the ability to restrict who can use certain runners in an org, similar to how we can restrict who has access to contexts.
Support auto-scaling for self-hosted runners
Automatic scaling to handle changing workloads - AWS ASGs, Kubernetes, etc.
Docker Based Runner for Behind-The-Firewall use
As a CircleCI SaaS user with Behind-the-firewall resources (artifacts, databases, services) I want to easily run select jobs on my internal network rather than CircleCI’s network. Unlike current Machine Runner: I should not need to define or publish custom images I don’t or won’t use for my other jobs in cloud. I should not need to manage dependencies or libraries on said runner (instead provided by my docker images). I should not need to recycle physical or virtual servers to get a clean build environment (instead provided via each docker container – as with cloud). In short, my existing cloud jobs should be easily ported to run on my docker runner in my internal network