Support test splitting on self-hosted runners
Although the parallelism feature does work on self-hosted runners, the downloading of previous test results is not currently supported - which means that the intelligent test splitting feature does not work. In addition, the standard circleci test split invocation of test splitting requires the circleci CLI or the circleci-agent binary to be available.
Installation Via Package Manager
To avoid the pit fall of missing a necessary command and to save time, it would be helpful if runner could be installed via a package manager.
Support add_ssh_key on self-hosted runners
To reach parity with existing non-runner jobs, the add_ssh_key ( https://circleci.com/docs/2.0/configuration-reference/#add_ssh_keys ) step should be supported. This will allow use of additional configured keys for pushing tags and generated-commits. The key should be added in a way that remains scoped to the runner job - and not globally on the hosting machine.
Workload Identity Support
CircleCi should support workload identity to allow pipelines to authenticate with cloud providers without requirement for secrets or certificates. Google and Azure does provide mechanisms to generate short lived tokens where the tenants doesn't have to extract secrets that could be leaked
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
Support auto-scaling for self-hosted runners
Automatic scaling to handle changing workloads - AWS ASGs, Kubernetes, etc.
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.
Add resource_class for Remote Docker Environment
Currently there is only one compute configuration for Remote Docker environments and it's pretty slow. https://circleci.com/docs/2.0/building-docker-images/#specifications I would like to have the same (or at least a better set of) resource_class options for our large image builds.
Parallel runs: Re-run only the container that failed
When running tests suites on multiple containers, using the parallelism features (see: https://circleci.com/docs/2.0/parallelism-faster-jobs/ ), it would be absolutely WONDERFUL if it would be possible to re-run only the container that failed (only the relavant part of the tests suite).
Running a job inside privileged docker on ‘machine’ executor
Implement behind-the-scene logic which allows one to seamlessly execute a job on a Docker container which runs on a 'machine' runner. Example configuration to be used to demonstrate the feature: version: 2.1 jobs: say-hello: machine: image: ubuntu-2004-cuda-11.2:202103-01 runs-on: docker: image: docker.io/account/example:latest # All steps will run inside this container privileged: True steps: - checkout - run: command: "echo hi there" # This will run inside the docker container