[pekk]

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 using this new tool solely for the sake of Concourse?); now I have to learn a new strange distinction between the otherwise similar English words "job" and "task," something about Garden (yet another hole to travel) and a new meaning for the acronym "TSA" and for some reason the command line utility is called "fly" which has no obvious relationship to the project name (what if the command to interact with git were "spudge"?) can I please just install a .deb and run a service and add a build real quick to try this out?

This could be why it is so common to see Jenkins deployed everywhere. While it is wrongly designed in so many frustrating ways, you can still set it up for real work in an hour or so, and you won't need a dictionary to translate from a unique new jargon into English just to try it out. Every new CI that makes this even one bit harder than Jenkins isn't trying hard enough.

[vito]

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.

[challiwill]

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 that it can feel like "turtles all the way down" (quoting @oblio from earlier today), but you do not need to jump in with BOSH right away.

In regards to how to think about 'job' vs 'task', I like to think of 'Job's as a description of what the module is attempting to achieve. For example in the Concourse team's own pipeline[1] you'll see a 'job' named "deploy". 'Task's are on the other hand the individual things that need to happen in order to complete the 'job'.

-- 1. http://ci.concourse.ci/

[mewse]

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 vagrant box in the first place.

I've had a brief struggle with trying to get the standalone executables to work under Linux, without any success (I'm told that they probably are incompatible with my server's kernel version; note that the documentation does not state what kernel or OS versions are supported). Similarly, I've had a brief look at what it'd take to set up an install using BOSH.. but it looks like that's going to be a massive undertaking.

As a practical matter, if you want to use Concourse for real work, you probably do have to jump in with BOSH right away, since the standalone versions are likely not to work with your VMs, and the vagrant version is missing critical features and hasn't even been updated to the 1.0 release.

[mewse]

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 it less painful to install on a proper server. I totally would jump on board in a heartbeat. But I've already spent a couple days trying to make it work, and I just can't afford to throw more of my time at it right now, particularly since I already have a fully functional (albeit somewhat unpleasant and occasionally unreliable) Jenkins install, which only took me 20 minutes to set up and configure.

I'd be very interested in taking another look if and when the whole install process has been streamlined somewhat! There's lots of promise here; I just can't get into it.

[jacques_chester]

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.

[kraig]

Or a simple 'docker run'

[mead5432]

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...