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

61–70 of 158 posts

Re: Concourse CI

#61

Post by wlamartin »

fatterypt wrote: post #57
nstart wrote: post #19

Not sure when it came about, but when I first evaluated Concourse, not being able to trigger jobs manually was a primary blocker. Glad this showed up on HN again, because they've added it in at some point. My favourite thing about Concourse was really its ideas around "Resources". This always felt so much better than this idea of plugins due to how unified the experience was. Also, the ability to implement resources…

This is also close to my experience. Improving, but not there yet. Unfortunately, it will retrigger the same job with the updated version of the resources. With other CI tools, it was possible to replay the same job, with whatever inputs they took by the time they ran, with concourse it does not seem t be possible. A practical impact of this issue is that we cannot simply reprocess a previous deploy step, with the ol…

You can achieve this by clicking on a resource and hitting toggling the "power button" to off for each of the resources you don't want to include in the build.

Re: Concourse CI

#62

Post by henryaj »

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.

Re: Concourse CI

#63

Post by henryaj »

webo wrote: post #11

Mostly off-topic but I've been looking for more than a CI for some quite time, more on the CD side. How are you guys handling some of these cases? Bonus points for hosted options. - Truly a pipeline based stages. No messing around with git branches/tags for each environment release. - Ability to combine multiple builds together. - Build dependencies. Ability to trigger project-B build when project-A build succeeds. (…

> Build dependencies. Ability to trigger project-B build when project-A build succeeds

Within a pipeline, you can 'pass' an output of one step as a triggering input to another. Across pipelines, you can use e.g. an S3 resource to save state; the job to be triggered looks at that S3 resource and triggers when it changes.

> Use the same artifact across multiple build stages.

Yep - you can pass the output of one job to be used as the input of another.

> Ability to combine multiple builds together.

Yep - have a look for "fan-in" in the docs.

> An option to promote a build to the next step either manually or automatically.

You can manually trigger steps from the UI; you could also have a resource that triggers a job automatically on some condition.

Re: Concourse CI

#64

Post by mugsie »

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 retriggering a CI run on a single PR (without force pushing to the branch, which removes Github reviews)

Jenkins + Jenkinsfiles + Pipelines provides all of the good bits of Concourse, with none of the Pivitol enforced workflow + tools.

I get why CloudFoundry uses Concourse - the build process is so arcane that you basically need to run the full CI locally, but I really do not get the hype for other projects.

Re: Concourse CI

#65

Post by fatterypt »

wlamartin wrote: post #61
fatterypt wrote: post #57

Earlier quoted context omitted.

This is also close to my experience. Improving, but not there yet. Unfortunately, it will retrigger the same job with the updated version of the resources. With other CI tools, it was possible to replay the same job, with whatever inputs they took by the time they ran, with concourse it does not seem t be possible. A practical impact of this issue is that we cannot simply reprocess a previous deploy step, with the ol…

You can achieve this by clicking on a resource and hitting toggling the "power button" to off for each of the resources you don't want to include in the build.

While this may even work, it is not practical and it is a disappointing experience for a pipeline centric type of CI such as concourse.

In other tools, hitting re-run would simply replay the job, with the same state it was executed in the first run. I would expect concourse to behave similarly, but no.

Re: Concourse CI

#66

Post by wlamartin »

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…

> That overlay network it comes with, garden thingy, creates so many problems and solves just one...

Can you expand upon this a little bit? Garden is the containerisation piece, what about it creates problems and what single problem do you think it is solving?

Re: Concourse CI

#67

Post by wlamartin »

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…

> not all things can run in garden

Can you provide an example of what you'd want to do but you aren't able to?

Re: Concourse CI

#68

Post by gaff33 »

sytse wrote: post #20
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…

Cool to hear you selected GitLab. We recently added multi project pipeline visualization. That was partially inspired by concourse CI. Is there anything else you would like to see?

Please can you allow for any acyclic graph rather than the current stage system? This would allow us to have our long running integration tests run in parallel with shorter tasks!

I wrote an issue for it here: https://gitlab.com/gitlab-org/gitlab-ce/issues/29347

Re: Concourse CI

#69

Post by pokemongoaway »

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…

Not everyone... Jenkins is probably the most versatile! I'm still a heavy user and enjoy using the official docker image these days :)

Re: Concourse CI

#70

Post by kapep »

Jedd wrote: post #60
superplussed wrote: post #53

Earlier quoted context omitted.

Of course both are acceptable, why is this an audacious claim?

Because it invites (not begs) the question 'to whom are they both acceptable?'. People that contribute to thefreedictionary.com, evidently.

thefreedictionary.com is only one of many dictionaries that use "myriad of" in their examples. Here are some more: http://www.yourdictionary.com/myriad

A quick Google Ngram search supports the claims from thefreedictionary, that "a myriad" or "myriads" was used first and that "myriad" as an adjective was only used later: https://books.google.com/ngrams/graph?content=%28myriad_NOUN...

It looks like "myriad of" has been correct in the past and is still used widely.

Post reply on HN