3 ms·

Can you share a bit more about this? I'm interested in setting this up myself. A link the docker image or name I can google? To be clear, you store all you

by acoard 6y ago

Can you share a bit more about this? I'm interested in setting this up myself. A link the docker image or name I can google? To be clear, you store all your code on Gitlab's servers (i.e. not self-hosting git instance) but just "outsource" the CI/CD work to your homelab? That's my ideal.

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 ago
  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.
- e12e 6y ago
  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.
- ddoice 6y ago
  Yep, I have a raspberry Pi with gitlab runner and works great.
usr1106 6y ago
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.

by acoard 6y ago

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 ago
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.
e12e 6y ago
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.
ddoice 6y ago
Yep, I have a raspberry Pi with gitlab runner and works great.

usr1106 6y ago

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.