4 ms·

GitLab Runner 1.1 with Autoscaling

56 points by sytse 11y ago

sytse 11y ago
We're very excited about allowing people to easily parallelize and scale their tests. Less waiting for CI for finish! AMA
- cm3 11y ago
  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.
  - ayufan 11y ago
    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.
    - asteadman 11y ago
      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.
      - ayufan 11y ago
        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/1722 https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/.... Most likely we will run the builds only once on the VM.
        sytse 11y ago
        We'll improve the warning with this updated information https://gitlab.com/gitlab-org/gitlab-ce/issues/14732 https://gitlab.com/gitlab-org/gitlab-ce/issues/14732
toddkazakov 11y ago
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?
- andridk 11y ago
  I have a per-job image specified in my build files. As I understand it, the runner image is just the default.
  - toddkazakov 11y ago
    Ah, ok. I just got confused here.
  - ayufan 11y ago
    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 :)
hanikesn 11y ago
What about using kubernetes for running gitlab ci?
- sytse 11y ago
  That would be awesome. But a merge request we had for that added a lot of dependencies to GitLab Runner. So we're still thinking about the best way. Suggestions are welcome. BTW Deploy to Kubernetes is easy via https://about.gitlab.com/2016/03/22/gitlab-8-6-released/ https://about.gitlab.com/2016/03/22/gitlab-8-6-released/

56 points by sytse 11y ago

sytse 11y ago

We're very excited about allowing people to easily parallelize and scale their tests. Less waiting for CI for finish! AMA

cm3 11y ago
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.
- ayufan 11y ago
  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.
  - asteadman 11y ago
    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.
    - ayufan 11y ago
      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/1722 https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/.... Most likely we will run the builds only once on the VM.
      - sytse 11y ago
        We'll improve the warning with this updated information https://gitlab.com/gitlab-org/gitlab-ce/issues/14732 https://gitlab.com/gitlab-org/gitlab-ce/issues/14732

toddkazakov 11y ago

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?

andridk 11y ago
I have a per-job image specified in my build files. As I understand it, the runner image is just the default.
- toddkazakov 11y ago
  Ah, ok. I just got confused here.
- ayufan 11y ago
  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 :)

hanikesn 11y ago

What about using kubernetes for running gitlab ci?

sytse 11y ago
That would be awesome. But a merge request we had for that added a lot of dependencies to GitLab Runner. So we're still thinking about the best way. Suggestions are welcome. BTW Deploy to Kubernetes is easy via https://about.gitlab.com/2016/03/22/gitlab-8-6-released/ https://about.gitlab.com/2016/03/22/gitlab-8-6-released/