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

Concourse CI Hits 1.0.0

concourse.ci

Post reply on HN
Print view View original

61–70 of 72 posts

Re: Concourse CI Hits 1.0.0

#61

Post by jacques_chester »

mewse wrote: post #58
mewse wrote: post #54

Earlier quoted context omitted.

Sadly, while it's easy to play with the software this way, the 'vagrant up' implementation is missing a bunch of functionality; you don't get any authentication functionality, and you don't get the ability to attach external workers. Also, as of right now, the vagrant build hasn't even been updated to the 1.0 release; it's still limited to version 0.76.0. So you can't play with this new Concourse release using a vagr…

And I just want to add.. I really like Concourse. I'd love to use it instead of Jenkins. But at the moment, I haven't been able to get it to work, apart from in a vagrant box running an old version of the software, which I can't deploy to a real server, and to which I can't attach workers. Which, from a brass-tacks point of view, means that I haven't be able to get it to work at all. I'd be thrilled if you can make i…

Speaking as a one-eyed Concourse fan, I think your remarks are fair and reasonable. My personal hope is that the binary version will be picked up by downstream channels (Homebrew, linux distros etc), which will simplify the experience for 99% of users.

Re: Concourse CI Hits 1.0.0

#62

Post by zoomzoom »

Have recently rebuilt CI systems at work, and took a look at Concourse alongside Jenkins, Buildbot and Gitlab. Seems like not so many people have mentioned gitlab on this thread, but in my experience it combines all the benefits of Concourse (pipeline-driven workflows, passing forward build artifacts, config in source control) with a much simpler architecture. Concourse looks so complex and has so many moving pieces to learn - BOSH, fly, etc...

Gitlab is just a rails app and then has a go-based runner to do the CI work. Omnibus packages make installation easy. They even have some autoscaling stuff for the runners using docker engine there which I still think needs some work for my use case but for may others is ready to go and looks awesome.

CI covers so many use cases and so there is lots of room for different alternatives, but make sure to check out gitlab if you're looking for the simplest and most flexible CI system I've yet to see :)

Re: Concourse CI Hits 1.0.0

#63

Post by kraig »

jacques_chester wrote: post #61
mewse wrote: post #58

Earlier quoted context omitted.

And I just want to add.. I really like Concourse. I'd love to use it instead of Jenkins. But at the moment, I haven't been able to get it to work, apart from in a vagrant box running an old version of the software, which I can't deploy to a real server, and to which I can't attach workers. Which, from a brass-tacks point of view, means that I haven't be able to get it to work at all. I'd be thrilled if you can make i…

Speaking as a one-eyed Concourse fan, I think your remarks are fair and reasonable. My personal hope is that the binary version will be picked up by downstream channels (Homebrew, linux distros etc), which will simplify the experience for 99% of users.

Or a simple 'docker run'

Re: Concourse CI Hits 1.0.0

#64

Post by zeisss »

vito wrote: post #36
oblio wrote: post #33

Earlier quoted context omitted.

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 Postg…

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 organizatio…

Also please add pictures. there is nothing beating a pictures with 3 boxes and arrows :P

Re: Concourse CI Hits 1.0.0

#65

Post by kkapelon »

jacques_chester wrote: post #60
kkapelon wrote: post #56

Congratulations for this release. However as already seen in the case of GoCD, the success of Concourse will depend on how easy it is to convince Jenkins believers. The "vs Jenkins page" needs to be augmented with more information regarding workers, plugins and simple jobs scripts. At the moment that page is not really convincing 1)"Jenkins servers become snowflakes" All configuration is saved on the disk as XML file…

I think it's less about putting a list of features in a spreadsheet and checking off boxes, and more about how the tool thinks. Jenkins can "do" the things that Concourse does, if you assemble enough plugins, click through enough configuration pages and write enough shell scripts. But that's not its native way of thinking. I agree that lots of Jenkins users will look at Concourse, scratch their head and leave it. But…

I don't disagree with anything you said. All I am saying is that the current "Concourse vs.." page does not really achieve anything.

People who like Jenkins will read it and say "Meh", while people who have already switched to Concourse (like you) don't need to read it in the first place.

Re: Concourse CI Hits 1.0.0

#66

Post by vito »

pekk wrote: post #51

I wish documentation would offer a "Concourse made easy" or something. I imagine the documentation is currently a work in progress. But starting for example from Github, it is extremely easy to go down a deep dark hole trying to figure out all the new terms: I guess I have to use BOSH, what is BOSH (itself a deep dark hole: uhh, stemcell? How does this relate to all the other similar tools? Why would I commit to usin…

I'm curious to know how your flow through the docs went. We inlined "getting started" into the main page, and had the Setting Up section show "vagrant up" first, and we have warnings above sections that are not critical to know before learning Concourse itself, which then take you right to "Hello World". It's already optimized for "Concourse made easy" - but perhaps our navigation is not?

I should probably add a warning above the BOSH section though, or even the binaries section.

The trouble is, reality is complicated, regardless of whether it's documented or not. I've found that a lot of open source projects simply don't document things to give an illusion of simplicity; people just forget all the manual labor they had to do after downloading that .deb and installing it across 10 machines and maintaining those machines over time. Our docs cover BOSH as our preferred tool for clusters. If you don't want to use BOSH, just use the binaries and your own deployment tool.

We don't build .debs yet; as soon as we do other people will want .yum, and another will want Docker images, so we built the binaries that will feed into those first, which is often what I look for when kicking the tires on something anyway.

Re: Concourse CI Hits 1.0.0

#67

Post by vito »

kureimoru wrote: post #57
vito wrote: post #36

Earlier quoted context omitted.

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 organizatio…

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

Re: Concourse CI Hits 1.0.0

#68

Post by sytse »

zoomzoom wrote: post #62

Have recently rebuilt CI systems at work, and took a look at Concourse alongside Jenkins, Buildbot and Gitlab. Seems like not so many people have mentioned gitlab on this thread, but in my experience it combines all the benefits of Concourse (pipeline-driven workflows, passing forward build artifacts, config in source control) with a much simpler architecture. Concourse looks so complex and has so many moving pieces…

Thanks for mentioning GitLab, glad to hear you like it!

We just officially released the autoscaling runner in https://about.gitlab.com/2016/03/29/gitlab-runner-1-1-releas... Please let me know what we can do to improve it for your use case.

Also see my other comment in this post https://news.ycombinator.com/item?id=11387327

Re: Concourse CI Hits 1.0.0

#69

Post by mead5432 »

challiwill wrote: post #52
pekk wrote: post #51

I wish documentation would offer a "Concourse made easy" or something. I imagine the documentation is currently a work in progress. But starting for example from Github, it is extremely easy to go down a deep dark hole trying to figure out all the new terms: I guess I have to use BOSH, what is BOSH (itself a deep dark hole: uhh, stemcell? How does this relate to all the other similar tools? Why would I commit to usin…

There is a simple 'vagrant up' you can do that allows you to play with Concourse without needing to learn about all the other tooling such as BOSH. It's a great way to get started. Take a look: Check out VM setup here: http://concourse.ci/vagrant.html Setting up first pipeline here: http://concourse.ci/using-concourse.html This gets you going with a local Concourse instance that you can experiment with. You're right…

I really wish there was a docker container for this. I was going to make one but didn't have the energy to dig into the documentation about installation from binaries. Maybe later...

Re: Concourse CI Hits 1.0.0

#70

Post by tobilg »

sytse wrote: post #50
tobilg wrote: post #49

Earlier quoted context omitted.

I'd love to see a Concourse.io vs. GitLab CI though... https://about.gitlab.com/gitlab-ci/

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 pipeline…

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.

Post reply on HN