Hacker News Reader

Comment by ozborn | Hacker News Reader

I'm a huge fan of Gitlab and use it at my workplace, but haven't upgraded to even 8.0 to try the continuous integration (CI) feature. Wikipedia makes it look pretty comparable on features to more mature CI system like Jenkins but can anybody here say how the current CI in Gitlab 8.x really compares?

View on HN

[We're running a Gitlab instance and one CI instance with multiple CI runners in the Google Cloud.]

Gitlab CI is great if you don't need dynamically provisioned build slaves, for which I found no integrated support. In general, Gitlab CI is much more straightforward and easy to use than Jenkins.

Jenkins wins when it comes to stuff like build artifacts (getting these out of Jenkins is easy peasy (just wget them and provide basic HTTP auth if needed), but with GitLab I have not yet found a way to automatically download say the latest build results), credentials management and other "more enterprisey" features.

Jenkins is easy to install on Debian-based systems; I have no real experience in setting up Gitlab other than via the official Docker images, which is nearly as easy as typing `apt-get install jenkins`. Setting up CI runners/instances is easy as well (apt-get install + one or two calls to gitlab-multi-runner).

Overall I'm pretty happy with Gitlab CI. Especially the fact that every developer in our company can take advantage of automated builds by just enabling CI support and putting a .gitlab-ci.yml in the repository is great. Over are the days were admins had to manage Jenkins jobs.

Artifacts: http://doc.gitlab.com/ce/ci/yaml/README.html#artifacts

Getting artifacts into gitlab CI is pretty straightforward.

But programatically pulling artifacts from gitlab CI does not seem to have a well-documented approach.

shouldn't your build tool do that? If your build creates artifacts, I'd imagine you'd want to store them in an artifact manager (Nexus, Artifactory, etc) or deploy them.

We're working on an artifact browser for 8.4. I assume an API for that will be trivial after that has landed.

You can follow the work in this in https://gitlab.com/gitlab-org/gitlab-ce/issues/3426

I gotta say, this is one of the killer features (for me) of gitlab. It's very actively maintained and constantly improving. (Nice to see that Mattermost is included automatically too, gonna have to enable that later and mess about with it!)

I sometimes have a similar issue with Travis CI, if I can't use one of their built in integrations or something. A simple workaround is to just upload an artifact to S3 after a successful build. Then on another system scan the bucket with a cron or listen for an S3 event notification for further processing. You can put a lifecycle policy on the bucket so it cleans up after a while too.

It's sort of annoying to have to add on another system to the pipeline, but I think it's generally reasonable. Managing artifacts shouldn't really be part of the CI system anyway, I feel it's better to handle that stuff separately.

I'm still using the old approach, which is adding a local directory as a docker volume, where all my artefacts are stored.

nginx then serves them under a unique path.

I would very much like to see gitlab offer the ability to get artifacts via some API so I can remove all that hackery.

We working on an auto scaling Runner for dynamically provisioned build secondaries. This uses docker machine so it works with most clouds. It will most likely land in 8.4 but we're not sure yet.

Definitely a huge fan of GitLab, best open source solution and super easy to host locally.

Gitlab CI is absolutely fantastic. I have a CI runner running on a Raspberry Pi under my desk and that thing just keeps running build jobs. The runner itself is an application written in Go that can run job locally or in a docker container.

I am curious about this as well. Is it a feature that has seen widespread adoption?

GitLab CI has been hard to use for a long time since we didn't devote a lot of time to it (less than 1 person). But we saw it got traction nonetheless and opted to integrate it in the main GitLab application in 8.0. Since then it's popularity is growing fast, we added a lot of features (most recently build artifacts) and we have more than 2 people working on it full time.

Reply on news.ycombinator.com