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

111–120 of 158 posts

Re: Concourse CI

#111

Post by falsedan »

kohsuke wrote: post #99
falsedan wrote: post #94

Earlier quoted context omitted.

> i don't think the Jenkins developers are interested in it either I keep running into this: we want to extend or change Jenkins behaviour, and since it's open-source, it's possible to get up-to-speed on the codebase & make that change. But getting it into a state which matches the mindset of the project maintainers is tough! Trying to convince someone that your use-case is not only permissible but is actually a good…

I'm the creator of Jenkins. Without fully knowing the context, I wonder if this is just a simple disconnect. In Jenkins, we collectively cover wide-ranging use cases not by making one existing plugin (say Git plugin) do everything, but by making it extensible so that other people can define additional semantics and behaviours as separate plugins on top of it. We learned this in the early days of Subversion plugin, ba…

Hi, thanks for responding!

Funnily enough, I'm specifically thinking of the Git plugin and issues like https://issues.jenkins-ci.org/browse/JENKINS-6124 & https://issues.jenkins-ci.org/browse/JENKINS-14572, and Nicholas de Loof's comments 'ur doin it wrong'. It's extremely difficult to extend this plugin; we have a lot of work tracking all the existing plugins we use, and adding maintenance of our own plugin on top of that is work we don't want to do.

Nowadays we try to keep as little as possible defined in jenkins configs and put our build & test logic in makefiles/tools.

Re: Concourse CI

#112

Post by PetrolMan »

manigandham wrote: post #90
PetrolMan wrote: post #86

Earlier quoted context omitted.

Interesting. How does it compare to other CI software like Jenkins? I'm always a bit skeptic about tools that look nice but turn out to be limited when put to real work.

Works well for us, docker/container native so every step in a pipeline is a persistent volume with the environment changing based on what image you need. Also easily builds/pushes your own images and lots of other built-in task runners to make pipelines. Has .yaml or ui config and they have an enterprise version which runs on-prem.

Thanks. Looks like worth giving a try indeed.

Re: Concourse CI

#113

Post by krakensden »

henryaj wrote: post #62
joeseeder wrote: post #44

Have been working with it for a few months, and I am not positive about it. UI is pretty but often breaks. Is unusable when you have a pipeline with dozens of concurrent jobs. Concept of teams is fine, but when you have to switch between them, even with oauth authentication, it is a pain. Job concurrency control is binary. We never have been able to have worker pool scale down without a hiccup, always some darn worke…

> UI is pretty but often breaks. Is unusable when you have a pipeline with dozens of concurrent jobs. Find this hard to believe - we have some pretty spectacular pipelines which render without a hiccup.

100+ jobs will break your browser. RabbitMQ has been complaining about it for a while.

Re: Concourse CI

#114

Post by witten »

grzesiekb wrote: post #45
witten wrote: post #23

Earlier quoted context omitted.

Interesting you should mention that. Right around the time you implemented multi-project pipeline visualization, we built a bot that listens for GitLab build completion events, hits the (undocumented /unsupported) internal GitLab global code search ElasticSearch index, finds downstream dependencies of the completed build (as declared in setup.py/package.json), and triggers their builds as well.. Taking full advantage…

Thanks for this proposal! It might be a cool feature indeed. I created an issue about it in our issue tracker, see https://gitlab.com/gitlab-org/gitlab-ce/issues/35186 . We do not have immediate plans to ship that yet, but I pinged our product team member there. However we do have plans to ship multi-project pipeline with an "inversion of control". You will be able to specify pipeline relation with an upstream projec…

Awesome, thanks for filing!

Re: Concourse CI

#115

Post by krakensden »

EngineerBetter wrote: post #26
fenollp wrote: post #4

Earlier quoted context omitted.

Probably easier to run Docker inside Vagrant than Docker inside Docker.

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.

Re: Concourse CI

#116

Post by rexpop »

skrebbel wrote: post #35

I hadn't heard of this, it looks nice! Would I be far off if I'd say that Concourse is an open source clone of Travis CI and CircleCI? Any strong pluses of the SaaS offerings over Concourse I should know about?

Distributed systems are first-class citizens of Concourse. It's a larger concept-space than Travis/Jenkins'.

Re: Concourse CI

#117

Post by krakensden »

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…

The really important things for me are, Concourse has no text boxes to edit in your browser, so it is possible to version and automate the configuration of your automation, and all Concourse resources (plugin equivalents) are zero dependency- so you can have multiple versions in one pipeline, and no accidentally breaking everything to get one new feature.

Re: Concourse CI

#118

Post by mugsie »

jadeklerk wrote: post #109
mugsie wrote: post #64

I know everyone hates on Jenkins these days, but (at least for the workloads I am building) Concourse feels like a toy. My issues: - everything has to be in a docker container (not all things can run in garden) - Just trying to find logs is a pain, and getting the UI to show a full log output is basically impossible - each install of concourse may need an entirely different version of fly - There was no way of retrig…

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

Re: Concourse CI

#119

Post by mugsie »

jadeklerk wrote: post #110
mugsie wrote: post #64

I know everyone hates on Jenkins these days, but (at least for the workloads I am building) Concourse feels like a toy. My issues: - everything has to be in a docker container (not all things can run in garden) - Just trying to find logs is a pain, and getting the UI to show a full log output is basically impossible - each install of concourse may need an entirely different version of fly - There was no way of retrig…

> - Just trying to find logs is a pain, and getting the UI to show a full log output is basically impossible What? It's just STDOUT.. Are your logs going to a file or something?

Well, yeah.

Different stages go to different log files, so you don't end up with a 10k log file.

Re: Concourse CI

#120

Post by mugsie »

jadeklerk wrote: post #108
joeseeder wrote: post #44

Have been working with it for a few months, and I am not positive about it. UI is pretty but often breaks. Is unusable when you have a pipeline with dozens of concurrent jobs. Concept of teams is fine, but when you have to switch between them, even with oauth authentication, it is a pain. Job concurrency control is binary. We never have been able to have worker pool scale down without a hiccup, always some darn worke…

> UI is pretty but often breaks. Is unusable when you have a pipeline with dozens of concurrent jobs. Are you running it on a potato? :) We have massive builds that have never had problems in the UI.

I have seen it, with not too many pipelines, and it just falls over. (and no, it is not a potato - its a pretty large bare metal machine)
Post reply on HN