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

11–20 of 72 posts

Re: Concourse CI Hits 1.0.0

#11

Post by jacques_chester »

raziel2p wrote: post #9
Jjarro wrote: post #6

Earlier quoted context omitted.

I have a handy heuristic about this: if you are interacting (directly or via a third party) with the filesystem of a service in order to use it, said service is probably solving your problem wrong. Try `fly`. It's worth it.

Funny, I use the opposite approach. If I can't configure and manage something via the filesystem, I usually stay clear of it. Specifically, not relying on the filesystem means I can't easily browse configuration, I can't have version control, and I can't use my configuration manager to have events trigger when things change.

I think there's some confusion. The actual config you send to a Concourse server is on your filesystem and ideally it's checked in.

`fly` is the CLI you use to tell the server "hey, here is a pipeline config", or "hey, I've changed the config, here's the new one".

Re: Concourse CI Hits 1.0.0

#12

Post by twic »

avtar wrote: post #7

For anyone else that got excited about having a Jenkins alternative, this project seems to be only about containers and not other workloads that VMs could tackle, such as running browser or desktop-based software tests. At least that's my understanding after giving the documentation a cursory glance. Could someone familiar with the project please confirm (or hopefully correct) this?

Some of my colleagues at Pivotal are running iOS builds with it. That is, they're running builds on a Mac which has an iOS device plugged into it. The workers are run using Houdini, which is a container management daemon that, er doesn't use containers:

https://github.com/vito/houdini

There's a blog post by someone else at Pivotal, although the details are probably a bit out of date by now:

https://blog.pivotal.io/labs/tech-talks/on-device-open-sourc...

Re: Concourse CI Hits 1.0.0

#13

Post by twic »

raziel2p wrote: post #4

I'm looking forward to experimenting with this. At least in the documentation, there seems to be a lot of focus on extra tools. BOSH seems very off-putting. Having to use the "fly" CLI command to update pipeline configuration seems unnecessary - can I just update the files on the filesystem myself, either via my configuration management tool or a git repository?

This is very much a trait of BOSH. When BOSH manages a machine, it owns that machine. It deploys the stuff that's specified in the manifest, but that has to come out of one or more 'releases', ie precisely structured tarballs of stuff, and there's no way to manage a file here or a setting there. You could push out a file by packing into a release, uploading that, and adding it to the manifest, but that's quite a ritual for one file. You are essentially expected to treat the machine as a black box.

As a result, BOSH-based systems tend to be managed via APIs exposed by the software running on them, which often come with a command-line tool. BOSH itself is like this, and so is Cloud Foundry.

This is a very different approach to tools like Puppet or Ansible, which are much more about openness and empowering the operator to directly manage machines. Although it is fairly similar to Docker etc, where you fire up images without any sensible way to fiddle with them, and rely on talking to the software.

So, if you are comfortable with the Puppet/Ansible type tools, then you won't like BOSH. This is 30% because BOSH isn't as good as them, but 70% just because it's different.

Re: Concourse CI Hits 1.0.0

#14

Post by topherbullock »

twic wrote: post #12
avtar wrote: post #7

For anyone else that got excited about having a Jenkins alternative, this project seems to be only about containers and not other workloads that VMs could tackle, such as running browser or desktop-based software tests. At least that's my understanding after giving the documentation a cursory glance. Could someone familiar with the project please confirm (or hopefully correct) this?

Some of my colleagues at Pivotal are running iOS builds with it. That is, they're running builds on a Mac which has an iOS device plugged into it. The workers are run using Houdini, which is a container management daemon that, er doesn't use containers: https://github.com/vito/houdini There's a blog post by someone else at Pivotal, although the details are probably a bit out of date by now: https://blog.pivotal.io/la…

As the author of that blog post I can confirm some of that is out of date. Hopefully I can find some time to update the post for 1.0, but the main concepts still work.

At Pivotal Toronto we're running iOS and Android builds using a mac mini as an external worker. What's been a great built in feature is using the pool resource to "check-out" a device and lock it from other tests while a suite is running.

Re: Concourse CI Hits 1.0.0

#15

Post by clem »

Does Concourse offer any integration with defect or agile development software that allows an easy way to track which builds contain a given feature or defect fix?

Re: Concourse CI Hits 1.0.0

#16

Post by twic »

jacques_chester wrote: post #11
raziel2p wrote: post #9

Earlier quoted context omitted.

Funny, I use the opposite approach. If I can't configure and manage something via the filesystem, I usually stay clear of it. Specifically, not relying on the filesystem means I can't easily browse configuration, I can't have version control, and I can't use my configuration manager to have events trigger when things change.

I think there's some confusion. The actual config you send to a Concourse server is on your filesystem and ideally it's checked in. `fly` is the CLI you use to tell the server "hey, here is a pipeline config", or "hey, I've changed the config, here's the new one".

No, i think raziel2p understands. If you're using a configuration management tool like Puppet or Ansible, by far the easiest way to manage a piece of software is through a configuration file on disk that the configuration management tool can manage directly: it's easy to see the current state, and to make changes. Anything that requires a tool or an API requires you to interpose some sort of update mechanism between the configuration management tool and the software, which doesn't have the transparency of a simple file.

Re: Concourse CI Hits 1.0.0

#17

Post by twic »

clem wrote: post #15

Does Concourse offer any integration with defect or agile development software that allows an easy way to track which builds contain a given feature or defect fix?

There is, predictably, an integration to Pivotal Tracker:

https://github.com/concourse/tracker-resource

I'm not aware of any others. It might not do quite what you want - it's more about pushing the progress of the CI pipeline into Tracker than about bringing information from Tracker into the CI pipeline.

However, resources are fairly easy to write:

https://concourse.ci/resources.html

So if your task tracker of choice has an API (or a command-line tool!), it should be kind of easy to build an equivalent.

Re: Concourse CI Hits 1.0.0

#18

Post by krishicks »

clem wrote: post #15

Does Concourse offer any integration with defect or agile development software that allows an easy way to track which builds contain a given feature or defect fix?

You can add a custom resource type (http://concourse.ci/resource-types.html) to add these integrations.

There's a Pivotal Tracker resource that does what you describe: https://github.com/concourse/tracker-resource

Re: Concourse CI Hits 1.0.0

#20

Post by jacques_chester »

twic wrote: post #16
jacques_chester wrote: post #11

Earlier quoted context omitted.

I think there's some confusion. The actual config you send to a Concourse server is on your filesystem and ideally it's checked in. `fly` is the CLI you use to tell the server "hey, here is a pipeline config", or "hey, I've changed the config, here's the new one".

No, i think raziel2p understands. If you're using a configuration management tool like Puppet or Ansible, by far the easiest way to manage a piece of software is through a configuration file on disk that the configuration management tool can manage directly: it's easy to see the current state, and to make changes. Anything that requires a tool or an API requires you to interpose some sort of update mechanism between…

Ah, gotcha. So if I'm following this line correctly, it'll need someone to write a wrapper that detects updates to .yml files and invokes fly?
Post reply on HN