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/

I 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.

The 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.

Yep, I have a raspberry Pi with gitlab runner and works great.

The link has already been provided. The runner is only an administrative process. It can be indeed put into a Docker container. The instructions are easy to follow, the image is built by gitlab and updated regularly. If you choose the alpine variant instead of latest it's much smaller. We have done that for 2+ years and not noted any limitations.

The runner will start jobs that do the real building (or whatever you have coded in your CI). Again you can choose to have jobs executed in docker containers. Also documented by gitlab, easy to set up. Of course you need to provide a suitable Docker image where your build can work. Nobody can do that for you. In simple cases you can pull something existing from Docker hub without further additions.