I mean, how does one determine whether to use an internal user DB (when there is none) or whether to piggy-back off of Unix user accounts, when running a JVM on a machine which does not use Unix style user credentials?
Is there a good resource with screenshots that show these new features? For a 2.0 that was in the making for years, the page is pretty light on screenshots.
Does Jenkins 2.0 use the same plugin based architecture as 1.0?
Does anyone actually prefer to use plugins for project types rather than a hand written build script? (i.e. using Jenkins to just kick off a shell script)
What does pipeline solve? When I start to set this up it looks like a build script wrapped in the Jenkins ui. So now we introduce yet another scripting language for build/deploy?
I was looking at this over the weekend to see if the risk/benefit ratio was appropriate for our team. Meh, we already use the pipelines plug-in, and the insecure-by-default configuration has already been locked down, so for our team the answer is, "no, it's not worth risking mikestew having to spend a day putting things back the way they were if the upgrade goes horribly wrong". I'm supposed to be writing code, not dicking around with broken installs.
That's not to poo-poo the hard work that obviously went into this release. Big, shiny new stuff there, and the next Jenkins box I setup will be running 2.0. But for my particular situation at this point in time, it'll be 1.6 for a while.
Couldn't agree more. Our current Jenkins box took several days to get fully operational, and upgrading just feels like too big a risk. Especially since it's so central to the developer workflow
I've always been afraid of updating Jenkins or the plugins because things always broke. Always.
That being said, I updated a few instances to 2.0, immediately applied all plugin updates and things kept working as before. That was a surprise. I was already prepared to spend hours trying to find why our jobs were failing. That was nice.
We have had problems but mainly with plugins. There's basically no mandatory QA process for plugins, nor is there any facility to make it obvious to an updater that an upstream change affects a downstream plugin and might break it.
In my opinion, Jenkins is a product that you really need to have a test instance for, where you either have copies of your builds or you've set up some 'unit test'-type builds to exercise functionality you depend on.
Jenkins has been good to me over the years, but DroneCI is where I'm at now. It's certainly not as powerful as JenkinsCI at this stage, but that's why it's an instant improvement for me.
I hope to see Jenkins, and the team behind them, stay strong within the industry for a long time :-)
Businesses where it didn't work fine don't usually openly advertise the fact they had to rewrite everything. Many of those that do stick with Apache Groovy often have restrictions on its use. Perhaps they only use the dynamic features of Groovy (the 1.x features), or only the non-Turing Complete DSL features like virtually every Gradle build script out there.
It also explicitly mentions backwards compatibility:
> Jenkins 2 is a drop-in replacement of the Jenkins 1.x series of releases and fully backward compatible. There is practically no reason not to upgrade!
I have used Jenkins many times and it's always worked fine. But I always wish TeamCity was more widely adopted and deployed. Sure, it costs money, but so does IntelliJ. And it's completely worth it.
Much nicer UI, nice support team at JetBrains. I found plugin writing to be pretty friendly once I got it set up though I've never written a Jenkins plugin to be fair.
Also very easy to define build pipelines in the UI.
I had never touched TC until my current role. I'm dumbfounded that they don't demo it more.
- You can backup / restore / version your entire CI config to a file = move fast and break stuff because it's easy to revert
- Build chains (pipelines in Jenkins) are built in, they're smarter than the average bear too
- Plugins not required, everything just works out the box, from report publishing to maven builds to connectivity with obscure VCS's - it's all just built in and there's no faffing about looking for combinations of plugins which play well together
To get started is as easy as any other CI server, however, because it's quite a bit more powerful than any other CI i've used, i'd say it takes a minute or two to fully appreciate what's on offer.
Might be worth noting that if you're using the ppa's from jenkins (http://pkg.jenkins-ci.org/debian/) you will 'get 2.0 for free' next time you update. It makes sense but I wasn't really prepared for this.
40 comments
[ 2.8 ms ] story [ 83.9 ms ] threadIs there a good resource with screenshots that show these new features? For a 2.0 that was in the making for years, the page is pretty light on screenshots.
The only thing I really wanted out of it was the checkpoint plugin, and that's still enterprise only.
it was not in making for years. 2.0 started only 4-5 months ago.
> This is why in 2.0 we’ve added the pipeline capability. This 2 year old effort allows you to describe your chain of automation in a textual form.
It seems that they have been working on some 2.0 features for two years.
Does anyone actually prefer to use plugins for project types rather than a hand written build script? (i.e. using Jenkins to just kick off a shell script)
That's not to poo-poo the hard work that obviously went into this release. Big, shiny new stuff there, and the next Jenkins box I setup will be running 2.0. But for my particular situation at this point in time, it'll be 1.6 for a while.
That being said, I updated a few instances to 2.0, immediately applied all plugin updates and things kept working as before. That was a surprise. I was already prepared to spend hours trying to find why our jobs were failing. That was nice.
I was already prepared to spend hours trying to find why our jobs were failing.
Yeah, that's exactly what I'm not prepared for, and trying to avoid. :-) No one pays the little Mac Mini on my desk much mind...until it doesn't work.
In my opinion, Jenkins is a product that you really need to have a test instance for, where you either have copies of your builds or you've set up some 'unit test'-type builds to exercise functionality you depend on.
I hope to see Jenkins, and the team behind them, stay strong within the industry for a long time :-)
Scripting languages like Apache Groovy don't scale, instead bring technical debt, complexity that must be fixed up by someone else in the future.
It also explicitly mentions backwards compatibility:
> Jenkins 2 is a drop-in replacement of the Jenkins 1.x series of releases and fully backward compatible. There is practically no reason not to upgrade!
Also very easy to define build pipelines in the UI.
See 'CraigJPerry answer also.
- You can backup / restore / version your entire CI config to a file = move fast and break stuff because it's easy to revert
- Build chains (pipelines in Jenkins) are built in, they're smarter than the average bear too
- Plugins not required, everything just works out the box, from report publishing to maven builds to connectivity with obscure VCS's - it's all just built in and there's no faffing about looking for combinations of plugins which play well together
To get started is as easy as any other CI server, however, because it's quite a bit more powerful than any other CI i've used, i'd say it takes a minute or two to fully appreciate what's on offer.
demo: http://ci.concourse.ci
FD: I work at Pivotal (but not on Concourse), the makers of concourse.
Yes we know there are alternatives to jenkins.
You likely want debian-stable instead: http://pkg.jenkins-ci.org/debian-stable/