4 ms·
You run an agent called the GitLab runner. You configure it with a token from your Gitlab.com group or repo (depending on where you want the runner to be availa
by time0ut 6y ago
You run an agent called the GitLab runner. You configure it with a token from your Gitlab.com group or repo (depending on where you want the runner to be available). You tag the runner and reference it by tagging CI jobs you want to run on it. The runner polls for outstanding jobs and then executes them. It is extremely flexible in how it does this. In our case, the runner manages a fleet of executors using docker+machine. I believe this is similar to how Gitlab does it internally.
See https://docs.gitlab.com/runner/ https://docs.gitlab.com/runner/
- lloeki 6y agoI did macOS runners this way, combining the runner with the VirtualBox executor. Best part is once you set up the base VMs (one per macOS version), the runner is smart enough to take a snapshot right after boot and restore that on subsequent runs, which not just makes job running stateless, but also makes job worker boot about 2s.
- e12e 6y agoThe ci/gitlab runner bit, might be the best part of gitlab - it's pretty straightforward to set up (we self-host gitlab and ci). The omnibus-installer (for gitlab itself) works - but knowing a bit about rails (gitlab is a ror monolith) - it's a bit terrifying. But the runner is very nice.
- ddoice 6y agoYep, I have a raspberry Pi with gitlab runner and works great.