gitlab-ci-runner
gitlab-ci-runner copied to clipboard
gitlabhq
Support for multiple runners
This patch allows multiple runners to build the same project in parallel, as each runner has its own, dedicated directory for checking out and building the projects.
No, that is not the point. Currently runner did repo checkout in tmp/builds/project-X When you run multiple runners, e.g. by changing RUNNERS_NUM=10 in gitlab-ci-runner, each of these will checkout to the same directory. All works fine when each runner is building different project. But when 2 runners build the same projects, they checkout project to the same directory, which causes problems (at least on my system). I build the patch for myself that adds another level of directory structure. The runner got irs number (0 by default), and each runner has its own build directory: tmp/builds/runner-R/project-X. This prevents 2 runners to checkout different commits into the same directory.
All except directory structure works as previously, thus until some build script rely on the directory structure where true build is performed, no changes in build scripts are needed.
Btw, writing this comment reminds me that I have not introduced change to init scropt, which I will do in a minute.
Ran across this exact issue the other day. Would be good to see this added in soon and released.
Combined with #98, we'd be able to configure the number of runners per machine without having to overwrite the default init.d script.
@n-e-g with your changes, how do the different runners show up in the runners web view? When I previously changed RUNNERS_NUM myself, it only showed one runner.
@robodude666 the runners share the same token so, from gitlab-ci they are seen as a single runner.
I also made some experiments with single token per-runner, but this change introduces many incompatibilities with existing scripts. (e.g. from bin dir.). Setup is more complex as well. I have already tried multiple config.yml files (config-[runner-id].yml). I am also experimenting with multiple tokens in single config.yml file.
If there are any ideas how to deal with this, please make some suggestions.
I was thinking about multiple workers again, and came across the following scenario:
What if the project's build script invokes Vagrant or Docker? You might end up running into issues if two of the same container are used at once, or if the same IP address is used at once in Vagrant, etc.
Easiest workaround is to always do vagrant up at the beginning of your script, and then vagrant destroy at the end; but then you're wasting a whole lot of time creating VMs are downloading packages, etc.
Alternatively, it can be put up to the user to ensure that a single worker is setup on a runner that's dedicated to the project.
Hey Guys, you maybe interested in: https://github.com/gitlabhq/gitlab-ci-runner/pull/99 and https://github.com/gitlabhq/gitlab-ci/pull/462. It's still WIP, but very promising.
I have been using this as a patch for the last few days and it seems to work really well. Currently running 20 runners with one project, and a load of developers - seems to work well and I haven't had a problem with it
:+1: for this, multiple runners trying to build the same project is causing us many problems. It seems silly that you can only run one runner per machine or they step on each other.
More specifically, that this system cannot handle any project where new commits ever come in faster than the test suite can run.
+1 for merge.
we're building Python buildouts with gitlab_ci_runner. we also ran into this.
Currently we are considering to make GO runner official https://github.com/ayufan/gitlab-ci-multi-runner It allows to run builds in parallel on the same machine.
@vsizov :+1:
The GO runner was much easier to install & setup. Would be cool to see if become the official runner, as it supports multiple operating systems, and even support configuring a multi-runner from GitLab CI.