Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitLab 10.6 released with CI/CD for GitHub

about.gitlab.com

Post reply on HN
Print view View original

71–80 of 107 posts

Re: GitLab 10.6 released with CI/CD for GitHub

#71

Post by lobster_johnson »

I've never used GitLab, and I'm curious if it's something my company could use.

Almost all our Github projects use Docker. We don't use automatic deploys at the moment, but CI basically consists of building a Dockerfile, then running tests with "docker-compose run", then pushing the image to GCR.

We do have some projects that consist of multiple dockerfiles, but they're outliers. Everything else follows the same convention.

We currently use Semaphore, which has several downsides:

* Every project needs to be created and configured individually. We have many, many small projects. On Semaphore, setting up a project requires clicking through 4 or 5 screens to configure. I know Semaphore has an API (two incompatible ones, actually), but that means we have to write code for something that should be included in the box.

* To alleviate this burden, we have a single shell script, hosted with HTTPS and basic auth, that every project runs to build. It does things like log into GCR, set up secret build args, then do the build. Again, stuff that's identical across all projects. It's a bit silly to fetch this script every time rather than have it be shared across the whole organization.

* Semaphore's Docker layer caching (achieved with docker pull + docker build --cache-from) seems inconsistent. Some builds are fast, some don't get any caching.

* Semaphore is terrible at describing test failures. You'd think that a CI system would be great at doing things like show "4 failures/2 skipped/123 successful" on some kind of board. But instead you just get success/failure, and the entire build log. If the test is something like "go test", then you get 99% noise, and it's hard to zero in on what the failure was. I'd love to get the actual failing test in the Slack notification.

We've tried a few alternatives:

* Self-hosted Drone: Great, but too immature when we ran it, and development seems slow, with the organization behind apparently focused on a SaaS solution?

* Google Cloud Container Builder: Better, but requires each project to be "mirrored" within Google Cloud, which is a pain, and the mirroring is flaky. Also, no layer caching. And apparently not appropriate for running Docker Compose tests, and secrets management requires more tendrils into GCP, whereas we prefer things to be ore self-contained.

* CircleCI: Similar problems as Semaphore. Seemed a bit messy.

* Jenkins: Nobody likes Jenkins, apparently.

Based on the above, would Gitlab be a better fit?

Re: GitLab 10.6 released with CI/CD for GitHub

#72

Post by mhugo »

IshKebab wrote: post #19

This is great, although I'll probably stick with Travis & Appveyor for my open source project since Gitlab.com currently only has Linux runners. All three currently have two big flaws IMO though: 1. They all use YAML which is an awful, unintuitive format. 2. The only way to test a configuration is to commit it and push it. Why is there no way to paste a config file in their website and run that? Hopefully one day we'…

Gitlab runners have different "executors". One of which is virtualbox. if you have a windows vm where you can ssh into, it works well

Re: GitLab 10.6 released with CI/CD for GitHub

#73

Post by gtirloni »

jobvandervoort wrote: post #61
gtirloni wrote: post #36

Earlier quoted context omitted.

It's open core , not open source. I'm pretty sure they would have a lot of incentives to turn it down.

We don't have a lot of incentives to turn down contributions. Quite the opposite. We not only encourage this, we actively help people contributing to GitLab. It's humbling to be a steward to an open source project and something we don't take lightly [0]. And to be blunt, for an organisation as ours, with very ambitious goals, and highly demanding users, having someone else than us contribute something that makes the…

That's reassuring, thanks for replying. I was commenting from a general perspective on open core licensing but I understand not all companies are created equal.

Re: GitLab 10.6 released with CI/CD for GitHub

#75

Post by ulm0 »

dogweather wrote: post #67
ninkendo wrote: post #2

Since "X adds support for Y" is nearly always ambiguous and confusing: It looks like GitLab's CI/CD system can now be pointed at GitHub repositories. So that means you can point your GitLab CI system at a GitHub repo and get build/test/deployment of your code, probably integrated with PR checks and so forth.

So GitLab's CI/CD is now modularized and theoretically can be used in place of Circle CI or similar?

Nope, it's not modularized, just a group of *-hooks to trigger, update and report pipelines (and their statuses) GitLab Github (a 2-way communication channel) you'll get the status when opening PRs right in GitHub and so on.

Re: GitLab 10.6 released with CI/CD for GitHub

#76

Post by Macha »

Thaxll wrote: post #18

I'm curious for the people that use GitLab CI/CD, what's the pro / cons vs Jenkins and the like?

So I use Gitlab CI on my personal projects, and in work I was "the Jenkins guy" on our team for a good while, though I've since changed projects to one using an internal tool so my Jenkins knowledge is ~1yr outdated.

Gitlab CI:

==========

+ No infrastructure required. I like to work on my private projects and not their servers.

+ Mostly-declarative syntax with a easy way out when required. Jenkins until recently only had imperative options (scripts in a UI/scripts in classic Pipeline)

+ Caching between builds is inbuilt, while in the past we had to roll our own with Jenkins

- No easy way to share the same script between repos without copy/pasting your .gitlab-ci.yml.

Jenkins:

========

+ More options to display output. Need to have your tests list which ones passed and which failed? Done.

+ Credential Management is better, at least at the "early adopter" free tier I'm on for Gitlab.

- The Legacy/Default UI is bad. The Blue Ocean UI is a bad UI in a winamp skin.

- Integrating plugins designed with pre-workflow jenkins in mind to Jenkins Pipeline is a bit awkward, often requiring you to know which class is used internally in the plugin.

Re: GitLab 10.6 released with CI/CD for GitHub

#77

Post by yashap »

tmuir wrote: post #70
victorwu wrote: post #66

Earlier quoted context omitted.

Thank you for the explanation. I've created an issue. Feel free to continue the discussion there. https://gitlab.com/gitlab-org/gitlab-ce/issues/44553

Does this mean that gitlab doesn't generally employ people to simply learn their competitors products, to keep informed of their offerings?

This is a highly unfair criticism, you’re never going to have total feature parity with your competitors, nor is that even a good thing to strive for.

Re: GitLab 10.6 released with CI/CD for GitHub

#78

Post by Macha »

lobster_johnson wrote: post #71

I've never used GitLab, and I'm curious if it's something my company could use. Almost all our Github projects use Docker. We don't use automatic deploys at the moment, but CI basically consists of building a Dockerfile, then running tests with "docker-compose run", then pushing the image to GCR. We do have some projects that consist of multiple dockerfiles, but they're outliers. Everything else follows the same conv…

Gitlab solves 1 (manual UI config for each build) and 3 (Docker image build time) at least in my experience, but it's caching is transparent so I don't know if you were using a less common image would it be slower. It doesn't solve 2, you'll need a .gitlab-ci.yml for each repo, and it has the exact same problem 4 (no way to drill down into test failures).

Re: GitLab 10.6 released with CI/CD for GitHub

#79

Post by smulc »

diggan wrote: post #22
Thaxll wrote: post #18

I'm curious for the people that use GitLab CI/CD, what's the pro / cons vs Jenkins and the like?

A short while ago (eh, just noticed this was over a year ago...) I did a comparison between different testing solutions for all projects within the IPFS organization. Remember this was a year ago, so many things have changed but we ended up going with Jenkins and I'm now migrating projects from free usage of Travis/CircleCI to Jenkins. - Brief explanation: https://github.com/ipfs/infrastructure/issues/100#issuecomme.…

Nice summary. Did you test support for handling multiple changes to a single project in parallel? The only CI Platform I've found that tries to handle this in any meaningful way is OpenStack Zuul (https://zuul-ci.org/) and https://docs.openstack.org/infra/zuul/user/gating.html#testi... for details of the parallel support.

Do others have this need? Or are people generally focusing on keeping CI runs short and landing changes in a serial fashion?

Re: GitLab 10.6 released with CI/CD for GitHub

#80

Post by Improvotter »

eslaught wrote: post #16

Gitlab's CI/CD is amazing. Of all the systems I've seen, it's the easiest to (a) deploy your own runners easily, and (b) mix private and public runners (i.e. the equivalent of using a free plan on Travis, with the benefit that for heavy-duty jobs you can run your own machines). That and first-class support for docker (no more being at the whims of what Travis chooses to deploy in their images), make it a really great…

I'm planning on open sourcing my service and was planning on using GitHub because I wanted to get people involved. However, currently I'm using a local server with Jenkins to poll GitHub for the deployment with a separate repository for deployment configuration. This isn't ideal and I'm not a huge fan of Jenkins itself in the first place. (It took a huge amount of time to setup!)

Could you explain more about how you've got public and private CI/CD setup? I'd love to get the tests to run publicly, but I'd love to deploy privately and not have all of that information right there in the repo because the plan is to offer it as a service as well.

Post reply on HN