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

141–150 of 157 posts

Re: Jenkins 2.0 Beta

#141

Post by zzzeek »

mschuster91 wrote: post #100
zzzeek wrote: post #35

Earlier quoted context omitted.

I can't imagine what you couldn't accomplish using the Parameterized Trigger Plugin https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Tr...

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.

Re: Jenkins 2.0 Beta

#142

Post by Sevein »

vito wrote: post #96
genericpenguin wrote: post #90

Earlier quoted context omitted.

I've been a heavy Jenkins user for the last three years and I can completely see where you (and Concourse team) are coming from. The page comparing Jenkins and Concourse hits all my right buttons (complexity in build specification, minimal pipeline, etc) but I find that having to BOSH the hell out of a new system (pun intended) just to get CI running seems like a PITA to me (it's the one thing preventing me from reco…

@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)?

Re: Jenkins 2.0 Beta

#143

Post by ipsi »

vito wrote: post #140
ipsi wrote: post #122

Earlier quoted context omitted.

Does this mean it will be (is?) possible to deploy Concourse on a single machine without the headache of BOSH Lite? I've wanted to use Concourse, but when all you've got is a Mac Mini, doing a full BOSH deploy (or even BOSH Lite) is quite a big ask.

Yup (is). You'd just run `concourse web` and then `concourse worker` on the same machine. If all you have is a Mac Mini there's one gotcha, though: currently none of the resources will run on OS X, as they're built as Docker images. So you'll still need at least one Linux worker somewhere. I think the next step from us may be to start building Vagrant boxes that just spin up a worker, parameterized with credentials t…

OK, that makes sense. Anything that makes it easier to deploy would be awesome, particularly when dealing with iOS-related CI/CD.

Re: Jenkins 2.0 Beta

#144

Post by ABS »

jacques_chester wrote: post #126
ABS wrote: post #43

Earlier quoted context omitted.

GoCD pipeline config is actually (sort of) declarative and stored in XML format in an internal git repo so it's versioned and you can recover/replay any version of it (in fact you can visualize the very first version of a pipeline you ran 3 years ago in the Value Stream Map visualisation and execute it again). Agreed that the format isn't ideal but there are non-trivial problems in breaking it down due to the advance…

Concourse avoids the fan-in/fan-out problems of GoCD's XML configuration by performing planning for you. That is, you define the inputs and outputs of a job, then Concourse derives how to carry out your jobs in the correct order under the correct conditions. A Concourse yaml file is pretty flat, as a consequence. That's a great writeup. I think you'd find Concourse attractive.

I played with Concourse when it was initially released but it wasn't there for us yet and at the moment there is no reason to change but definitely need to test it again.

I couldn't find any docs on intra pipeline dependency management though, any links?

Thanks!

Re: Jenkins 2.0 Beta

#145

Post by oblio »

Rezo wrote: post #135
oblio wrote: post #66

Earlier quoted context omitted.

TeamCity is cute, but at scale its pricing is... kind of bad. $12k for 50 agents. And it's not that hard to have 50 Jenkins slaves, especially if you're testing on multiple platforms or on different versions for those platforms.

If you have 50 Jenkins slaves, you probably have someone who's job is almost exclusively to babysit Jenkins. At my two previous workplaces, we had entire release teams focused on that, and still Jenkins was a never ending source of problems. And they did everything "right", all the Jenkins scripts and configs were in git etc. $12K/month for a much (I mean, it's like going from cvs to git) better solution in that situ…

Well, from my experience as the person who "babysits Jenkins" unless you appoint an actual owner for Jenkins, you'll get a real tragedy of the commons with it. Devops sounds cool and all but most devs want to write cool code: usually product features, not infrastructure stuff, so everyone will do CI/CD related work half-heartedly.

So in my obviously biased opinion, if your team is big enough, either get an actual build/release engineer/devops guy or appoint one of the devs as an owner for this, otherwise you won't get the best results.

Re: Jenkins 2.0 Beta

#146

Post by Joky »

radicalbyte wrote: post #120
Joky wrote: post #93

Earlier quoted context omitted.

You have simple problems to suggest simple solutions. CI logic can gets complicated: What about cascade builds? The pipeline can't be handled in your build script. What about reporting? (list of compiler warnings in the build? List of tests that failed? In general extracting information from the log) What about efficient email alert? (with blame list, list of changes, etc.) What about IRC reporting? Jenkins is not ve…

Huh? I really don't understand your argument. Jenkins is better than scripts because you can do more in Jenkins than in scripts? O_O You can do a heck of a lot more in scripts; you've got a full language with all of the libraries it comes with in order to do stuff. We've build our current build pipeline with Python scripts: 0. Bootstrap the build environment (installs everything you need to build). 1. Build projects…

I was basically answering "If you're putting lots of logic into ANY CI server you're doing it wrong!".

There is a separation of concern: the CI server logic is a refactoring of things that are common to any project. If your project have scripts that sends email on build failure, I think you're doing something wrong.

You mention at some point "orchestration scripts", this is exactly what Jenkins is supposed to provide help with: orchestration.

The important thing IMO is that the boundaries of responsibilities are clearly defined between what a project does and what the orchestration does.

Re: Jenkins 2.0 Beta

#147

Post by carterehsmith »

jacques_chester wrote: post #13

It's great to see that Jenkins is following the path blazed by GoCD[1] and Concourse[2] to make the pipeline concept more central. That said, this appears to be achieved by promoting the plugin into the default installation. It also misses some of additional the advantage Concourse holds over Jenkins and GoCD: build configuration is purely declarative and can be checked in with the project. You know what version of y…

Wait, what? Jenkins can do whatever pre-processing/post-processing you need by means of tasks. Regular Ant/Maven/Java tasks. And that was there, in production, from the time immemorial. People have been doing that for a decade now.

GoCD and Concourse add... what?

Re: Jenkins 2.0 Beta

#148

Post by jacques_chester »

carterehsmith wrote: post #147
jacques_chester wrote: post #13

It's great to see that Jenkins is following the path blazed by GoCD[1] and Concourse[2] to make the pipeline concept more central. That said, this appears to be achieved by promoting the plugin into the default installation. It also misses some of additional the advantage Concourse holds over Jenkins and GoCD: build configuration is purely declarative and can be checked in with the project. You know what version of y…

Wait, what? Jenkins can do whatever pre-processing/post-processing you need by means of tasks. Regular Ant/Maven/Java tasks. And that was there, in production, from the time immemorial. People have been doing that for a decade now. GoCD and Concourse add... what?

Or I could use Makefiles. Or just write a giant single bash script which only works on three workstations in the office.

GoCD and Concourse make the connections as important as the individual jobs. Concourse goes further and makes checked-in configuration and disposable containers the basis of the build environment.

This sounds like no big deal, but it's critical.

The point is not whether Jenkins can "do" these things. With the right stew of plugins, it can. The point is that Jenkins does not really think this way. It starts with the Single Ball of Build as the unit of work and retrofits other possibilities.

Re: Jenkins 2.0 Beta

#149

Post by jacques_chester »

ABS wrote: post #144
jacques_chester wrote: post #126

Earlier quoted context omitted.

Concourse avoids the fan-in/fan-out problems of GoCD's XML configuration by performing planning for you. That is, you define the inputs and outputs of a job, then Concourse derives how to carry out your jobs in the correct order under the correct conditions. A Concourse yaml file is pretty flat, as a consequence. That's a great writeup. I think you'd find Concourse attractive.

I played with Concourse when it was initially released but it wasn't there for us yet and at the moment there is no reason to change but definitely need to test it again. I couldn't find any docs on intra pipeline dependency management though, any links? Thanks!

I'd have to ask around; I imagine the Cloud Foundry release engineering team have some tricks up their sleeves.

As for my own project, we have an increasing group of downstream consumers of our API. There are a few ways I could signal upgrades. They could just watch my repo and narrow it to the directories they're interested in. I can also publish a file on S3 or push into a git repo that they watch.

Re: Jenkins 2.0 Beta

#150

Post by robbiemitchell »

mbrock wrote: post #115
robbiemitchell wrote: post #110

Earlier quoted context omitted.

This is a critical component of releasing production software. I would not expect to see "free" in the conversation here.

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 toward other alternatives if a wider business context is taken into consideration.

Post reply on HN