Hacker News new | ask | show | jobs
by jacques_chester 3738 days ago
I work at Pivotal, which sponsors Concourse development, so I got one of the fancy t-shirts we made for this occasion.

I wore it to the office today. Other people in the office were coming up to me and raving about Concourse. I've been proselytising it, but I feel like pretty soon I just won't have to. One of my colleagues was telling me that in two days he got an iOS CI pipeline that he never managed to achieve with weeks of tinkering with TeamCity.

I suspect that pretty soon the default choice for CI/CD in Pivotal Labs projects will be Concourse, and that will seed it pretty widely.

If you want to get in on the ground floor of something great, here's a good opportunity.

If you're wondering about what the heck it is, go to the homepage for the 40,000 view: http://concourse.ci/

If you're wondering why the heck another CI system, look at "Concourse Vs.": http://concourse.ci/concourse-vs.html

After that my advice is to look at public Concourse pipelines and pop the hood. And drop into the Slack channel, the team are in there now posting funny gifs. I'm in there too, under jchester_robojar, if you want to ask me anything.

3 comments

Can you ELI5 Concourse's architecture? (I haven't installed it yet, it's possible that some of my follow up questions are answered by installing Concourse and testing it a bit)

I saw this page (http://concourse.ci/architecture.html) but it's turtles all the way down...

Or just validate if my understanding is correct:

Concourse has the following components:

* ATC: web UI + job scheduler; can be clustered; uses PostgreSQL as data storage; => this would be a part of the "master" in Jenkins terminology

* TSA: simple SSH server, used by workers to register and presumably be controlled; => this would be the second part of the "master" in Jenkins terminology, in a sort of JNLP Jenkins setup where the workers register with the master instead of vice versa (Jenkins SSH connection)

* workers: Cloud Foundry type containers (WTF is Cloud Foundry exact? their page is totally confusing); "slaves" in Jenkins terminology

Also, if I read the features correctly, Concourse supports both Linux and Windows builds, right?

You pretty much got it right. That page is still a bit rough; we'll give it some TLC soon.

Workers are just machines running a container management daemon (much like a Docker daemon) and a volume manager (a custom daemon for managing caches and efficient artifact propagation between containers). Not sure how you got to Cloud Foundry though, it's not really related. Garden lives in the Cloud Foundry GitHub organization, as it's also used by Cloud Foundry, but you don't need to know anything about CF to use Concourse.

Concourse supports Linux, Windows, and OS X. You can see an example of this here:

https://ci.concourse.ci/pipelines/main/jobs/fly/builds/2621

I will jump in with a question: what about FreeBSD? Can I have a FreeBSD slave / Garden?
If someone writes a Garden backend for it, sure. Here's an example of a pretty small backend that delegates to `systemd-nspawn`:

https://github.com/vito/garden-systemd

Also please add pictures. there is nothing beating a pictures with 3 boxes and arrows :P
Is Windows support on the roadmap?
Woops, typo'd in my original comment: it supports Linux, Windows, and OS X. :) Binaries here: http://concourse.ci/downloads.html
I've been trying to figure this out from the docs, but how does it support Windows? In the sense that for now (until Server 2016 comes out), you don't really have "container support".
Concourse just talks to Garden, it's up to the Garden backend whether or not it actually does containerization. So on Windows it just does the world's worst containerization (cd'ing into a directory), though it at least guarantees that the processes all die.

There's a proper Garden Windows backend in the works which we'll switch to at some point once we better understand it: https://github.com/cloudfoundry/garden-windows

More links:

Concourse's own CI: https://ci.concourse.ci and Concourse Slack: http://slack.concourse.ci

Concourse really seems like a nicer Go.CD, in terms of how pipelines, jobs and resources work. I'm quite interested to see how it can work for a fully Docker-based workflow (each git repo has a Dockerfile in the root, that we want to rebuild whenever the master branch receives a new commit. Then we run the image in a container, execute our tests, then if the pass export the Docker image and pass it on to the staging server, start up a new container and shut down the old one).
Building a docker image is relatively straightforward. You define the docker image resource, then "put" to it.