We choose docker-machine, because it also manages infrastructure, so this makes it much more easier for Administrators to manage hundred of build machines.
I'm thinking about an option to make it possible in one of the upcoming releases: how to scale gitlab-runner on other providers. You should look out for improvements in that department too!
This is only tangentially related, but information on the runtime environment of gitlab.com's shared runners is a little obtuse. Is using a shared runner with a private repository a no-go if I want to keep my repo private? All I can find is the cryptic warning "GitLab Runners do not offer secure isolation between projects that they do builds for. You are TRUSTING all GitLab users who can push code to project A, B or C to run shell scripts on the machine hosting runner X." I take this to mean that I have to trust everyone who can push code to the shared runner, which for all intents and purposes is anyone with a gitlab account.
This was problem in the past. Since we use Docker we have fairly good separation of builds. You are not able to fetch someone other source unless you find or use linux kernel exploit. This will get improved further with upcoming upgrades to shared runners offering: https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/.... Most likely we will run the builds only once on the VM.
That would be great, I'm not married to the implementation as much as the convenience of using the cluster manager we already have (kubernetes) to distribute builds.
I currently am using a VM with a docker runner, and there are two (somewhat obvious) issues:
* It requires root access to the machine to be able to spin up containers
* Every VM with a docker runner needs enough storage to handle every docker image used for builds, instead of centralizing the images. I really need to put in a cron job or something to clean these up.
Kubernetes should fix both of these, without introducing another technology in our environment like Docker Machine.
At this point it doesn't make sense to introduce support for another clustering manager. The GitLab Runner does support docker-machine (you can pretty easily configure it to create machines on-demand on any cloud provider). These machines will be pretty much self-managed. Soon the Runner will be also compatible with Docker Swarm, the implementation is already on separate branch.
From my perspective Kubernetes is great as platform for deploying applications, but I'm not so sure if it comes for distributing builds.
What is important that GitLab Runner is being constantly improved and at some point with more convincing (for example coming from You) we can get back to native Kubernetes executor :)
Previously we had problems with usernames/groups that had upper case letters. The recent improvements (8.5) fixes all these problems. Please try it now :)
GitLab CI Lead