[jperras]

I very much appreciate the "Concourse vs." page[1] which compares Concourse to several other CI solutions, but I wish they would include Buildbot[2]. Everyone always forgets about Buildbot!

Buildbot can integrate with Docker to run tasks on containers, create complex conditional flows with triggered builds/steps (among others), and has been in use for many years at organizations large & small.

While the YAML based Concourse configurations seem very useful, we've found that for many non-trivial pipeline style builds are better served by being written in a fully functional language like Python. It has some disadvantages compared to a declarative approach taken by Travis & Concourse, but I feel that they outweigh the limitations imposed by the latter.

The next version of buildbot is also being refactored into a core + plugins system, which should allow for some pretty impressive flexibility that should serve the needs of almost everyone.

--

1. https://concourse.ci/concourse-vs.html 2. http://docs.buildbot.net/latest/

[challiwill]

I'm not familiar with Buildbot, but the benefit you're describing I think exists in Concourse as well. When you define a task you can just point it to a script to run. This can be a script written in a higher level language if you'd like.

This is similar to how some Concourse Resources are implemented with Shell[1] scripts, and some in Go[2]. -- 1. https://github.com/concourse/git-resource 2. https://github.com/concourse/tracker-resource

[tobilg]

I'd love to see a Concourse.io vs. GitLab CI though...

https://about.gitlab.com/gitlab-ci/

[sytse]

We too! During making GitLab CI we had a good look at Concourse. We love what they made and think it is great. The pipeline view is great. For us it inspired http://doc.gitlab.com/ce/ci/triggers/README.html and https://gitlab.com/gitlab-org/gitlab-ce/issues/750910

GitLab CI is similar to Travis CI in how it works. The page lists three things about Travis CI:

1. Unfortunately it still doesn't have support for pipelines

2. only very simple builds are possible.

3. if something doesn't pass in CI you normally need to send up lots of little debugging commits to work out why it's behaving differently

GitLab CI has does the following to address this:

1. As mentioned GitLab earlier has triggers and we're working on per project pipeline views

2. Builds in GitLab can have many stages with parallelism per stage, since today you can pass build artifacts between stages and cache items https://about.gitlab.com/2016/03/29/gitlab-runner-1-1-releas...

3. You can test the runner locally with exec https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/...

Please let me know what is missed and what people need that we need to add to GitLab CI

[tobilg]

First of all: Thanks for your excellent work on GitLab! We're evaluating it currently, and it quickly replaced our SVN and TeamCity workflows for some of our projects.

I love the lightweight approach with GitLab CI, it's really easy to get started with. I currently don't miss any significant functionality, but I guess our builds are not that complex.

As we're running our complete infrastructure on Mesos/Marathon, I wonder whether it'd be possible to use the new autoscaling for the runners with Marathon instead of docker-machine. Basically, the only thing I'd need to be able to is to retrieve the registration token for the runners via a API, so that it can be passed in when the new Docker container(s) is/are spun up.

Currently (we're still using the old runner version in a custom Docker image, https://hub.docker.com/r/tobilg/gitlab-runner/), we scale them manually via Marathon.

Probably it's easy to integrate Mesos/Marathon additionally to docker-machine, because the mechanism for scaling seem to be the same.

I think this will be beneficial to Mesos users, bescause it will be very easy to use and scale GitLab on it.

[ayufan]

Thanks tobilg.

We choose docker-machine, because it also manages infrastructure, so this makes it much more easier for Administrators to manage hundred of build machines.

I'm thinking about an option to make it possible in one of the upcoming releases: how to scale gitlab-runner on other providers. You should look out for improvements in that department too!

GitLab CI Lead

[sytse]

Thanks Kamil. For other people reading and interested in computing platforms that we support also see https://gitlab.com/gitlab-org/gitlab-ce/issues/14812