12 comments

[ 1.5 ms ] story [ 34.1 ms ] thread
We're very excited about allowing people to easily parallelize and scale their tests. Less waiting for CI for finish! AMA
Does GitLab runner imply that I can move my open source projects to GitLab free edition and have integrated CI without the need to sign up at Travis-CI AND also including Windows support? That would be spectacular.
Currently Shared Runners offer only Linux-based builds. We can introduce extensions to that offering at some point.

The Linux-based Shared Runners are free for everyone, including for private projects.

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.
It's a pity that you specify the docker image in the runner configuration. Wouldn't it be better if this is specified in the build file in the repo?
I have a per-job image specified in my build files. As I understand it, the runner image is just the default.
Exactly. The image specified during registration is the default one.

You can override the image globally in .gitlab-ci.yml or on per-job basis. Full flexibility here :)