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

Jenkins 2.0 Beta

jenkins.io

Post reply on HN
Print view View original

151–157 of 157 posts

Re: Jenkins 2.0 Beta

#151

Post by thawkins »

robbiemitchell wrote: post #150
mbrock wrote: post #115

Earlier quoted context omitted.

There are good reasons to prefer free and open systems, even for "production" software. Those reasons are part of why people choose to use GNU/Linux, nginx, and all the rest of the open infrastructure.

It was not clear whether it was free as in beer or speech. I do understand there are benefits to using open software. Too often I see engineers bias heavily toward inexpensive, free/cheap, or home-built solutions simply because they personally don't think things should cost money, when the understated anchoring costs of building and maintaining, plus the opportunity cost of valuable people time, might shift the towar…

It's never the cost for me, it's the mutability, oos I can hack on, and make it do exactly what I want it to do, proprietary code I only ever seem to get somewhat close but never exactly there.

Re: Jenkins 2.0 Beta

#152

Post by mbrock »

robbiemitchell wrote: post #150
mbrock wrote: post #115

Earlier quoted context omitted.

There are good reasons to prefer free and open systems, even for "production" software. Those reasons are part of why people choose to use GNU/Linux, nginx, and all the rest of the open infrastructure.

It was not clear whether it was free as in beer or speech. I do understand there are benefits to using open software. Too often I see engineers bias heavily toward inexpensive, free/cheap, or home-built solutions simply because they personally don't think things should cost money, when the understated anchoring costs of building and maintaining, plus the opportunity cost of valuable people time, might shift the towar…

Yeah, I parsed them as wanting a free system as in one that's open source, but I could be wrong.

If we're talking about hosted solutions, I agree it's mostly silly to refuse to pay... unless we're talking about open source projects, where many CI vendors do have a free tier...

Anyway, I also see an opposite bias toward costly hosted proprietary solutions and a refusal to even think about how one could accomplish one's goal with, say, a couple of shell scripts and cron jobs—or a self-hosted open source system.

That bias can be very sensible, but it can also be a hindrance, especially when it turns out that the proprietary solutions aren't quite what you want anyway, but since you're opposed to writing your own scripts, or running a more flexible system on your own servers, you settle for a suboptimal setup...

This bias I'm talking about is also a way of undervaluing something. It's saying "I'll pay $99/month for some hosted thing, but I'll never spend a week of engineer effort on really getting it right."

Re: Jenkins 2.0 Beta

#153

Post by vito »

Sevein wrote: post #142
vito wrote: post #96

Earlier quoted context omitted.

@vito from the Concourse team here. We've recently started building standalone binaries which should lower the barrier to entry. Concourse itself has never been too tightly coupled to BOSH, it's just been the quickest feedback loop for us during development, so it ended up being the first thing we documented, primarily for internal use as we haven't really "launched" yet. Binaries are available for download in the Gi…

Are there plans to support other container managers (other than Garden-based managers)?

The nature of Garden is to support container managers as Garden backends. Garden itself is just a client/server API spec.

For example, [Guardian](https://github.com/cloudfoundry-incubator/guardian-release) is in the works to replace the Linux backend with a thinner runC-based backend.

The main value we get from it is having a nice Go API and not having to overhaul everything using Garden every time some shiny new container tech comes out.

Re: Jenkins 2.0 Beta

#154

Post by sytse »

Roritharr wrote: post #130
sytse wrote: post #31

It is clear that build stages should be first class citizens. We based GitLab CI on the awesome work that GoCD and Concourse did in this respect. Our DSL allows you to assign jobs to stages https://gitlab.com/gitlab-org/gitlab-ce/blob/43e49f52e30199c... and jenkins seems to have picked a similar syntax. What is interesting is that Jenkins has a DSL but that this is not part of the repository. This means that it is ha…

I might be an absolute DevOps Newbie, but getting GitLab CI to do a simple "copy to this ssh destination" buildscript seems very complicated. From what I could gather it means that I have to create a specific runner whose login credentials are in its config, which aren't accessible via the WebUi, only as a file on the server where the runner is running and give it an unique tag. Then in my repofile i have to select t…

Thanks for the feedback. Deployment with GitLab CI is still harder than it should be and we're working on it in https://gitlab.com/gitlab-org/gitlab-ce/issues/3286

If you want to securely store login credentials consider using secure variables http://doc.gitlab.com/ce/ci/variables/README.html

Re: Jenkins 2.0 Beta

#155

Post by mschuster91 »

zzzeek wrote: post #141
mschuster91 wrote: post #100

Earlier quoted context omitted.

Cool, thanks for that. I'll mail this one to our infrastructure team, but it's sad to see that this isn't installed by default.

how does it being an optional plugin change anything vs. Jenkins having every possible useful thing pre-installed resulting in a much more complicated setup screen? Plugin architecture is total win IMHO.

Parameters without the ability to pass them on is kind of pointless, imho the right solution is to provide a single "parametrization" plugin.

Re: Jenkins 2.0 Beta

#156

Post by Roritharr »

sytse wrote: post #154
Roritharr wrote: post #130

Earlier quoted context omitted.

I might be an absolute DevOps Newbie, but getting GitLab CI to do a simple "copy to this ssh destination" buildscript seems very complicated. From what I could gather it means that I have to create a specific runner whose login credentials are in its config, which aren't accessible via the WebUi, only as a file on the server where the runner is running and give it an unique tag. Then in my repofile i have to select t…

Thanks for the feedback. Deployment with GitLab CI is still harder than it should be and we're working on it in https://gitlab.com/gitlab-org/gitlab-ce/issues/3286 If you want to securely store login credentials consider using secure variables http://doc.gitlab.com/ce/ci/variables/README.html

Why so complicated? As a first step Please give me a Deployments Page that gives me the option to run simples SH Scripts in the Runner on click, parameterised please. All I need is a nice GUI for my QA people that allows them to deploy(which for our PHP site basically just means copy and DB Import) Branch x on Server y.

Jenkins is total Overkill for that but GitLab CI doesnt leave me with enough GUI to skip it either.

Re: Jenkins 2.0 Beta

#157

Post by sytse »

Roritharr wrote: post #156
sytse wrote: post #154

Earlier quoted context omitted.

Thanks for the feedback. Deployment with GitLab CI is still harder than it should be and we're working on it in https://gitlab.com/gitlab-org/gitlab-ce/issues/3286 If you want to securely store login credentials consider using secure variables http://doc.gitlab.com/ce/ci/variables/README.html

Why so complicated? As a first step Please give me a Deployments Page that gives me the option to run simples SH Scripts in the Runner on click, parameterised please. All I need is a nice GUI for my QA people that allows them to deploy(which for our PHP site basically just means copy and DB Import) Branch x on Server y. Jenkins is total Overkill for that but GitLab CI doesnt leave me with enough GUI to skip it either…

I agree that we should have a simple page that shows you an overview, our issue for this is https://gitlab.com/gitlab-org/gitlab-ce/issues/750910
Post reply on HN