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

91–100 of 158 posts

Re: Concourse CI

#91

Post by SHyx0rmZ »

paloaltokid wrote: post #5

Concourse is a really amazing piece of software, but the BOSH requirement I think will keep adoption low for small companies.

Shameless plug: I've been maintaining three Concourse clusters and have created https://github.com/SHyx0rmZ/concourse-debian to package the binary for Debian, so I can get away with just upgrading to a new package whenever a new version releases. It's far from perfect yet, but I'm happy to receive some feedback and planning to move my package repository and pipeline to the public soonish.

Re: Concourse CI

#92

Post by randallsquared »

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.

And people who contribute to the OED, in both the 1989 and 2003 editions, evidently.

http://www.oed.com/view/Entry/124538

http://www.oed.com/oed2/00154839;jsessionid=AC4DB817EFBADA5F...

I have had similar experiences, though, where I was convinced that some word or phrase usage was just incorrect, and where it turned out that I had just not happened across it. Fortunately, a minute of research can today fix any such misconceptions!

Re: Concourse CI

#93

Post by falsedan »

mugsie wrote: post #85
samueloph wrote: post #84

Earlier quoted context omitted.

Jenkins has some serious problems when you want to work with CD. Its currently impossible* to use Jenkins in a CD environment where you want to deploy by tagging your git project[1] and allow rollbacks because Jenkins doesn't treat tag's hashes (only the commits the tag points to). Unfortunately, hack such a fix is not very pleasant either, because Java, and i don't think the Jenkins developers are interested in it e…

> Jenkins has some serious problems when you want to work with CD. When you want to work with CD in a particular way. A simple fix to the above issue would be to have a "production" branch. When you want to do a release, you merge to the production branch. A roll back would just be a revert of the commits since the last merge to production, and could even be tagged. If you are doing CD by allowing devs to tag random…

> When you want to work with CD in a particular way.

I think that I, as the user of the project, should get to decide how I want to deploy my software. So, yes, I do want to CD things in a particular way: one that matches my developer's expectations and my business requirements.

> CD

Jenkins isn't a deployment tool. It can act like one, but this (rollback) is a classic example of how it's a build, not release, tool.

To address OP's complaint: we rebuild steps from the previous pipeline to perform a rollback, and we have all our deployment logic in a separate system which works with commit IDs, if the previous pipeline has been pushed out of the list of recent pipeline runs.

Re: Concourse CI

#94

Post by falsedan »

samueloph wrote: post #84
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…

Jenkins has some serious problems when you want to work with CD. Its currently impossible* to use Jenkins in a CD environment where you want to deploy by tagging your git project[1] and allow rollbacks because Jenkins doesn't treat tag's hashes (only the commits the tag points to). Unfortunately, hack such a fix is not very pleasant either, because Java, and i don't think the Jenkins developers are interested in it e…

> 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 idea over ticket comments is not what we want to spend our time on.

Re: Concourse CI

#95

Post by arsenico »

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

Re: Concourse CI

#96

Post by falsedan »

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

I used Octopus Deploy for .Net, it was amazing. It did releases as first-class objects (a collection of versioned packages pulled from a repository), per-environment configs, parallel execution of steps, rolling windows (for bouncing a few hosts at a time), pre- & post- activate scripts, and great IIS integration.

There was talk of Python + Linux support a few years back, a shame that didn't take off.

Re: Concourse CI

#97

Post by mugsie »

falsedan wrote: post #93
mugsie wrote: post #85

Earlier quoted context omitted.

> Jenkins has some serious problems when you want to work with CD. When you want to work with CD in a particular way. A simple fix to the above issue would be to have a "production" branch. When you want to do a release, you merge to the production branch. A roll back would just be a revert of the commits since the last merge to production, and could even be tagged. If you are doing CD by allowing devs to tag random…

> When you want to work with CD in a particular way. I think that I, as the user of the project, should get to decide how I want to deploy my software. So, yes, I do want to CD things in a particular way: one that matches my developer's expectations and my business requirements. > CD Jenkins isn't a deployment tool. It can act like one, but this (rollback) is a classic example of how it's a build, not release, tool.…

> I think that I, as the user of the project, should get to decide how I want to deploy my software. So, yes, I do want to CD things in a particular way: one that matches my developer's expectations and my business requirements.

Sure - it definitely is. But we all have to do that within the limitations of the tools we use. Jenkins makes an assumption (in the default mode) of a continuously moving HEAD - which may or may not be what you want. It doesn't make Jenkins bad - it makes it not suitable for your use case.

FWIW - adapting to using a moving HEAD is not that hard - `git reset && git commit -a -m "Revert deploy && git tag && git push` - but I totally understand why people would not like to use that style. It is a personal / culture choice.

Re: Concourse CI

#98

Post by mugsie »

falsedan wrote: post #94
samueloph wrote: post #84

Earlier quoted context omitted.

Jenkins has some serious problems when you want to work with CD. Its currently impossible* to use Jenkins in a CD environment where you want to deploy by tagging your git project[1] and allow rollbacks because Jenkins doesn't treat tag's hashes (only the commits the tag points to). Unfortunately, hack such a fix is not very pleasant either, because Java, and i don't think the Jenkins developers are interested in it e…

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

Yeah - it is a "problem"[0] with open source - you need to deal with people that may have completely objectives to you.

It is easier with a closed source / paid service to ask for feature requests. Remember that the maintainers probably get hundreds of similar requests a week, and have merged things in the past that they didn't like and later caused issues.

This causes confirmation bias for them "The last time we allowed code not aligned to codeing styles / test requirements / feature direction / $reason it all went badly", so it is easier to ask for things to align to their world view before merging it.

Being a maintainer is hard - you are damned if you do, and damned if you don't. People give out about not merging code, but they also give out if the code that does get merged breaks things. Finding a balance is hard.

0 - I don't personally think it is a problem, but it potentially requires a bigger time investment, and can be infuriating when you have a small change that really scratches an itch for you.

Re: Concourse CI

#99

Post by kohsuke »

falsedan wrote: post #94
samueloph wrote: post #84

Earlier quoted context omitted.

Jenkins has some serious problems when you want to work with CD. Its currently impossible* to use Jenkins in a CD environment where you want to deploy by tagging your git project[1] and allow rollbacks because Jenkins doesn't treat tag's hashes (only the commits the tag points to). Unfortunately, hack such a fix is not very pleasant either, because Java, and i don't think the Jenkins developers are interested in it e…

> 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, back when that was the most popular version control system. Everyone uses a generic tool like that very differently, so as we kept adding individually valid use cases to the Subversion plugin, it became this giant hair ball not just for devs but also for users.

This mode also works better for those who do not want to spend time explaining why their use case is a good/important one, as they can simply code up their idea as a separate plugin and move on.

With all that said, I'm sorry for the frustration you had. Do you still have some pointers to tickets/PRs, etc? I'd like to look into it.

Re: Concourse CI

#100

Post by arwineap »

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…

There is a drain / purge endpoint you could look into for scaling down workers.

Admittedly I don't do it often, but I haven't experienced a problem with it when I have.

Post reply on HN