[zimbatm]

Avoid! Concourse looks good on the surface but it's really not that great.

The UI is clunky.

The abstraction layer is too low and leads to a lot of repeated YAML. Which leads to YAML programming.

There are simple scenarios like deployment rollbacks who are hard to do.

For some reason they decided to develop their own container engine which leads to all sorts of trouble and maintenance issue. It's generally slow and we had 100% CPU usage when the worker was doing almost nothing.

I have used for 4 months and it was only problems. Gitlab CI is much better. Or even Jenkins is better.

[jadeklerk]

> Concourse looks good on the surface but it's really not that great.

I've used teamcity, jenkins, gocd, circleci, concourse, and travisci. For multi-project systems, concourse is king. (I like travisci for by-itself, non-system projects)

> The UI is clunky.

What? You just said the UI looks good... It's simple and clean; everything is async javascript (no page loads).

> The abstraction layer is too low and leads to a lot of repeated YAML. Which leads to YAML programming.

Which is an intentional choice. If you don't like YAML, use one of the MANY yaml abstraction layers of your choice...

> There are simple scenarios like deployment rollbacks who are hard to do.

First of all, a CI system shouldn't be your answer to rollbacks. Your deployment system should handle that. Secondly, assuming your deployment system can do rollbacks, concourse has on-fail jobs that can trigger rollbacks just fine.

> For some reason they decided to develop their own container engine which leads to all sorts of trouble and maintenance issue. It's generally slow and we had 100% CPU usage when the worker was doing almost nothing.

garden is used because cloudfoundry builds it. It is not slow... it is a light layer on top of runc (as opposed to docker which is a rather heavy layer on top of runc). You should pretty much never have to care about it, and in 3 years of using concourse I haven't had to - and we have some pretty gnarly large pipelines.

Also I call rubbish on your 100% CPU. I have two workers t2.xlarge workers running 22 and 30 containers (like, right NOW) and neither is above 10% CPU (which, actually, I should make those a lot smaller). Don't run workers on a potato and you'll be fine.

> Gitlab CI is much better. Or even Jenkins is better.

Ohhh you're trolling.

[zimbatm]

> What? You just said the UI looks good... It's simple and clean; everything is async javascript (no page loads).

I meant that when just looking at the website, Concourse looks good in terms of what it has to offer. For example it offers proper build pipelines, something that is lacking in most other CIs.

Maybe it's clean to you, I found that our developers where generally confused by how the releases were working.

> Which is an intentional choice. If you don't like YAML, use one of the MANY yaml abstraction layers of your choice...

I don't mind YAML too much but adding a templating language on top is generally clunky. Gitlab CI also uses YAML, can also build pipelines and doesn't require to generate the YAML.

> Also I call rubbish on your 100% CPU.

It might have been due to a misconfiguration (we were using c4.4xlarge). I bet that you have deployed Concourse using BOSH, the only truly tested deployment method.

[jacques_chester]

> Also I call rubbish on your 100% CPU. I have two workers t2.xlarge workers running 22 and 30 containers (like, right NOW) and neither is above 10% CPU (which, actually, I should make those a lot smaller). Don't run workers on a potato and you'll be fine.

I was on CF Buildpacks for a while, which is one of the earliest and more intensive users of Concourse.

Earlier versions of Concourse did stumble upon fairly hairy btrfs bugs that would enthusiastically choke CPUs to death if you had more than about 100 containers on a worker. This was particularly bad if, for any reason, you had a lot of jobs launching at once (I'm looking at you, 6-releases-simultaneously-NodeJS).

I can't remember if it was fixed by a kernel upgrade or whether they ditched btrfs. Either way it got fixed and I haven't seen it since.

Disclosure: I work for Pivotal.

[jacques_chester]

> The UI is clunky.

The UI was originally designed with one end in mind: "Show me what is broken and take me there as fast as possible".

I and others have given lots of feedback about the strengths and limitations of that orientation, particularly trading off between a job-oriented and resource-version-oriented view of the world.

> There are simple scenarios like deployment rollbacks who are hard to do.

I've had this with the CF resource. The Concourse-y solution would be an undeploy resource.

> For some reason they decided to develop their own container engine which leads to all sorts of trouble and maintenance issue.

The container engine is garden-runc, the actual containerising is the same code as Docker's. What I like a lot less is container orchestration. I have complained about this in a ha-ha-only-serious matter.

Disclosure: I work at Pivotal.