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

Concourse CI

concourse.ci

Post reply on HN
Print view View original

121–130 of 158 posts

Re: Concourse CI

#121

Post by mugsie »

jadeklerk wrote: post #107
abraham_s wrote: post #105

I evaluated concourse CI and I was impressed by the concept. Pros - Setup was really easy.(I didn't use bosh). - Both server and build pipeline configuration (Yaml file) are easy to backup and recreate. Cons - When I evaluated it , it had a few bugs which forced me to restart the server almost daily to keep it working. It should be more stable now. -

Did your evaluation happen a long time ago? Or, another question... did you run the binaries and appropriately screen them? I had the same problem until I realized I sucked at making a binary live a long time, and my eyes were opened to screen :)

Never run long running services in screen. Use a proper init system - screen is not the solution.

Re: Concourse CI

#122

Post by mugsie »

wlamartin wrote: post #88
mugsie wrote: post #75

Earlier quoted context omitted.

Booting VMs is kind of the main one.

Booting VMs on your worker seems like exactly the kind of debris concourse is encouraging the avoidance of by enforcing the containerisation of your builds. That said, I can't think of a reason why you couldn't boot a VM in a privileged Garden container, have you tried?

Yeah - I can't remember the actual failure, but it did not work out well.

We also need the VMs to survive across build steps.

We are working on an P/IaaS - so integration testing requires actually booting a full stack, then running an install, then testing the resultant servers are actually running Kubernetes

Re: Concourse CI

#123

Post by larkost »

i386 wrote: post #33
rjzzleep wrote: post #16

I've been eyeing Concourse and Go.CD over Jenkins for a while. The main criticism I saw on Jenkins and Go.CD vs. Concourse was that Jenkins Pipelines aren't first class and that it's easier to export configuration(in that regard Concourse > Go.CD > Jenkins). On the other hand Jenkins and Go.CD supports extensions, which Concourse touts as a feature. I also want the CI builds to create my base boxes with packer in mul…

How are Pipelines not first class in Jenkins? Pipelines are provided in the default installation and they are the first thing we talk about in the docs https://jenkins.io/doc/pipeline/tour/hello-world/ Disclosure: I work on Jenkins.

I have to agree with the poster. Piplines are very definitely not first-class objects: - There is no way (in the default installation) of re-running a stage without running the whole job again. - I can't see the history of a stage. - Pipelines are a plugin, that only relatively recently became a default one - They seems be the anointed new path, but live side-by-side with other branching methods like the Matrix plugin at this point.

This is all in-line with the "everything is a plugin" methodology, but in my mind that way of thinking is one of the biggest hindrances to Jenkins, second only to the lack of a real database powering it.

Re: Concourse CI

#124

Post by wlamartin »

mugsie wrote: post #122
wlamartin wrote: post #88

Earlier quoted context omitted.

Booting VMs on your worker seems like exactly the kind of debris concourse is encouraging the avoidance of by enforcing the containerisation of your builds. That said, I can't think of a reason why you couldn't boot a VM in a privileged Garden container, have you tried?

Yeah - I can't remember the actual failure, but it did not work out well. We also need the VMs to survive across build steps. We are working on an P/IaaS - so integration testing requires actually booting a full stack, then running an install, then testing the resultant servers are actually running Kubernetes

Ah that's a shame, I still suspect it would _probably_ work with the right tweaking but I appreciate there's a hurdle there that might be frustrating to overcome and that's no good.

We also test a PaaS and require VM spin up but we call out to GCP/AWS as necessary.

Re: Concourse CI

#125

Post by wlamartin »

krakensden wrote: post #115
EngineerBetter wrote: post #26

Earlier quoted context omitted.

Concourse doesn't run Docker, it uses something called Garden to run OCI containers from Docker images. Those containers can run the Docker daemon though, if you like.

The version of Garden it uses basically just shells out to Docker. Run 'top' on a busy Concourse worker, it's fun.

Garden makes use of runc (an Open Container Initiative project with a lot of contributions from Docker), in the same way containerd (component included in Docker) makes use of runc to run images. You won't find the docker engine being used by Garden.

Edit: I _think_ what you're likely seeing (if you are seeing docker in the top output) is Concourse using the docker-image-resource to pull images for your tasks to a local docker registry.

Re: Concourse CI

#126

Post by smgoller »

mugsie wrote: post #122
wlamartin wrote: post #88

Earlier quoted context omitted.

Booting VMs on your worker seems like exactly the kind of debris concourse is encouraging the avoidance of by enforcing the containerisation of your builds. That said, I can't think of a reason why you couldn't boot a VM in a privileged Garden container, have you tried?

Yeah - I can't remember the actual failure, but it did not work out well. We also need the VMs to survive across build steps. We are working on an P/IaaS - so integration testing requires actually booting a full stack, then running an install, then testing the resultant servers are actually running Kubernetes

I second what wlamartin said. We have pipelines that do integration tests that spin up 30 instance clusters in AWS. Trying to spin up something similar inside a concourse worker just isn't worth trying.

Re: Concourse CI

#127

Post by jadeklerk »

mugsie wrote: post #118
jadeklerk wrote: post #109

Earlier quoted context omitted.

> - There was no way of retriggering a CI run on a single PR (without force pushing to the branch, which removes Github reviews) A CI that runs one job (test) for lots of branches is differnet than a multi-pipeline CI that runs lots of jobs for a single branch (which is what concourse aims to be).

Sure, but if a job fails for a transient reason, there should be a way to retrigger it - that is just a basic feature of nearly all CIs, no matter how many jobs there is.

Of course, and you can - you can manually hit the + button to retrigger a build, and if you want specific inputs you can select the exact one you want in the resources tab (which is slightly less common, since you probably haven't been committing since your build broke, but it's totally doable).

Re: Concourse CI

#128

Post by witten »

mariusmg wrote: post #43
witten wrote: post #14

I took part in evaluating Concourse CI for the needs of my company (30+ devs). While it has amazing CI pipeline capabilities, we ultimately didn't select Concourse because it felt much more like a CI toolbox, requiring some development to put those tools to use. And what we really wanted was more of a turnkey CI product. Perhaps ironically, we ended up doing some development around the edges of the CI product we ulti…

>requiring some development to put those tools to use The best CI is the one where you write code to build/deploy etc. Wrangling with some moronic UI exposed by the CI product to abstract code is simply wrong. Don't do CI/CD like this.

Some development is fine (and expected). And indeed the goal of "build automation" was what led us to evaluate both Concourse and GitLab. We were previously on Bamboo, which really did require wrangling with a moronic UI.

But I think there's a difference between a mostly complete CI product with API extension points, and a "batteries not included" CI toolbox.

Re: Concourse CI

#129

Post by witten »

arsenico wrote: post #95

Curious to know why no one actually mentions Bamboo - definitely a great alternative to Jenkins, especially for those, who are into Atlassian infrastructure.

At least last I looked, Bamboo requires manual configuration of all builds. This doesn't scale to more than a handful of build plans. It also doesn't have much in the way of modern CI pipeline functionality.

Re: Concourse CI

#130

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

Post reply on HN