Introducing zero-configuration GitLab CI | Hacker News Reader

Introducing zero-configuration GitLab CI

githost.io

46 pointsjoshfng11 comments

GitLab B.V. CEO here, we think GitHost.IO has done a wonderful job to make it very easy to set up a CI solution for organizations. I've tested it and was able to set up a coordinator with a couple of runners in 5 minutes. This is a really cost effective way to test multiple pull/merge requests in parallel. I'll be in this thread for a few hours.

I've used GitLab a bit, and it seems to be a pretty simple self-hosted imitation of GitHub that does 99% of what I need to do for team code hosting. How does GitLab CI compare to Travis CI? Is it as flexible and seamless as Travis' GitHub integration? Right now I mostly use Jenkins, but more than half my projects could conceivably be run through something like Travis with minimal changes...

GitLab CI integrates directly with GitLab CE installs, requiring no configuration from the end user. Compared to Jenkins, it will automatically link up with your repo and start builds on commits and pull requests. These are things you have to manually configure with something like Jenkins. As for Travis CI, the integration is just as seamless. GitLab CI talks to GitLab installs via the CE api and automatically pulls in your projects, sets the build status on your repos and assigns runners to perform your builds. The GitLab team has really done an amazing job building a CI offering that integrates really well with their CE repo app.

I'm interested in knowing how GitHost are hosting GitLab CI. I'm currently using GLCI to run integration tests in Vagrant VMs, which unfortunately means most "cloud" hosting is out.

joshfng (Assuming you are from GitHost). Do you know if your environment would support this?

All of our CI instances (coordinators and runners) are based on Ubuntu 12.04 x64 images. You are free to install any sort of software needed to run your builds on the runners.

Hey joshfng. Thanks for the info, but it's more the BIOS settings I'm interested in.

For example DigitalOcean's Ubuntu 12.04 x64 images work fine with Vagrant/VirtualBox, and their CPUs support VT-x. However since they do not enable VT-x in their BIOS you can only run x86 guests.

If you could let me know the output of these commands in your images before I drop $10 to try it out it would be much appreciated:

$ cat /proc/cpuinfo| grep 'vmx' # Checks for VT-x support on the CPU.

$ rdmsr 0x3a # Checks if VT-x is enabled in the BIOS.

VT-x is not enabled in the bios of our cloud images. Is there a specific need to run the build inside of a nested vm, as opposed to running directly in the runner itself? Feel free to email me jfrye [at] githost.io to discuss further.

Also, forgot to mention you can try GitHost for free. There is no upfront billing.

Oh awesome, I didn't see that anywhere. I appreciate that mine is a strange edge case so thanks for all your help.

A pretty cool service for Gitlab CI, when will they add https support?

Https support will be added to CI instances within the next few days.

Reply on news.ycombinator.com