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

81–90 of 157 posts

Re: Jenkins 2.0 Beta

#81

Post by unclebucknasty »

robbyt wrote: post #27
jquast wrote: post #23

Having been using jenkins several times since it was Hudson, as well as Bamboo, travis-ci, python buildbot, and TeamCity, Jenkins is a loser from my perspective. Not worth becoming invested in. Its simply too difficult to use by a laymen developer or sysadmin when accommodating complex buildchains, which only grow more complex over time in most software businesses. If you're going to program your CI with a web admini…

Yes, software is harder to manage (long-term) when the primary interface is a GUI. However, the new Jenkins 2.0 fixes many of the issues you've described. Build pipelines are a major new feature, as well as the integration of a "Jenkinsfile" which allows configuration of jobs via a proprietary DSL.

Ugh. Not another proprietary DSL.

There is something amiss in the tech world these days. Too much esoterica and too many specialized tools, too many points of failure and dependencies, and too much duct tape. But, mostly, too much reinvention for frequently incremental "gains".

It seems normal, but it's really a mess. Environments are overly complex and it's a wonder anything works half the time.

At some point we will completely jump the shark. From there, my bet is there'll be a powerful movement towards simplicity.

/rant

Re: Jenkins 2.0 Beta

#82

Post by vorg »

teraflop wrote: post #28

It's cool that they're promoting the "pipeline" plugin to a built-in feature, but the devil is in the details. Under the hood, it's implemented by taking a script written in a "DSL" (it's actually Groovy code), transforming it into continuation-passing style, and serializing its state. This is pretty cool from a theoretical CS perspective, but having played with it a little bit, the implementation seems very fragile.…

> Under the hood, it's implemented by taking a script written in a "DSL" (it's actually Groovy code)

It's Groovy code? The announcement page doesn't mention "Groovy" anywhere, let alone "Apache Groovy" which is what the backers of Groovy are meant to refer to it as since last November (2015) when it was promoted from the Apache incubator by the ASF.

Re: Jenkins 2.0 Beta

#83

Post by GFK_of_xmaspast »

unclebucknasty wrote: post #81
robbyt wrote: post #27

Earlier quoted context omitted.

Yes, software is harder to manage (long-term) when the primary interface is a GUI. However, the new Jenkins 2.0 fixes many of the issues you've described. Build pipelines are a major new feature, as well as the integration of a "Jenkinsfile" which allows configuration of jobs via a proprietary DSL.

Ugh. Not another proprietary DSL. There is something amiss in the tech world these days. Too much esoterica and too many specialized tools, too many points of failure and dependencies, and too much duct tape. But, mostly, too much reinvention for frequently incremental "gains". It seems normal, but it's really a mess. Environments are overly complex and it's a wonder anything works half the time. At some point we wil…

But all the lisp people always talk about how incredible it is that one can have all sorts of DSLs....

Re: Jenkins 2.0 Beta

#84

Post by teraflop »

vorg wrote: post #82
teraflop wrote: post #28

It's cool that they're promoting the "pipeline" plugin to a built-in feature, but the devil is in the details. Under the hood, it's implemented by taking a script written in a "DSL" (it's actually Groovy code), transforming it into continuation-passing style, and serializing its state. This is pretty cool from a theoretical CS perspective, but having played with it a little bit, the implementation seems very fragile.…

> Under the hood, it's implemented by taking a script written in a "DSL" (it's actually Groovy code) It's Groovy code? The announcement page doesn't mention "Groovy" anywhere, let alone "Apache Groovy" which is what the backers of Groovy are meant to refer to it as since last November (2015) when it was promoted from the Apache incubator by the ASF.

Yep. You'd think this kind of thing would be considered significant enough to mention, but apparently not. They do mention it in the "tutorial", which AFAICT constitutes the entirety of the official documentation: https://github.com/jenkinsci/workflow-plugin/blob/master/TUT...

> A pipeline is a Groovy script that tells Jenkins what to do when your Pipeline is run.

Re: Jenkins 2.0 Beta

#85

Post by twic »

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…

> You know what version of your pipeline built the software at any point in its history.

Source control can tell you when changes to the pipeline were checked in, but they actually take effect when they're applied with 'fly set-pipeline'. That may be before or after they were checked in. Perhaps a sensible team would set up a pipeline to watch the pipeline repository for changes and apply them automatically. Mine hasn't.

> Concourse boils the unit of extension down to "resources"

Which you can only actually use by forking the Concourse BOSH release to add them to the workers [1]. I'm not sure i'd honestly call it a point of extension.

[1] https://github.com/concourse/concourse/blob/master/jobs/grou...

Re: Jenkins 2.0 Beta

#86

Post by gnoway »

brown9-2 wrote: post #65
pswenson wrote: post #30

Earlier quoted context omitted.

being able to config jenkins via code is huge! looking forward to trying it

You can do this today with the Job DSL plugin.

You can do this today with the same Pipeline plugin they are announcing as a major feature for 2.0. It's been available for months.

Re: Jenkins 2.0 Beta

#87

Post by techman9 »

yamitty11 wrote: post #42
jquast wrote: post #32

Earlier quoted context omitted.

Absolutely, tasks/system commands should always be stored in VCS as a shell script, so that feature branches can exercise changes in the task itself. Unfortunately theres the other 90% to worry about, and thats where the highest complexity is, such as configuring a build chains, access control, reporting, etc. Glad to see jenkins is moving towards a travis-ci ".travis.yml" kind of format, but I'm not hopeful to see i…

Could use something like this if you are using github https://github.com/groupon/DotCi Job configurations can be version controlled and reviewed like everything else. For multijob pipelines checkout https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Plugin

JJB is also a nice tool that seems like it allows similar functionality (I haven't worked with DotCi, so I can't say how they compare)

http://docs.openstack.org/infra/jenkins-job-builder/

Re: Jenkins 2.0 Beta

#88

Post by stormbeta »

nod wrote: post #46
jquast wrote: post #23

Having been using jenkins several times since it was Hudson, as well as Bamboo, travis-ci, python buildbot, and TeamCity, Jenkins is a loser from my perspective. Not worth becoming invested in. Its simply too difficult to use by a laymen developer or sysadmin when accommodating complex buildchains, which only grow more complex over time in most software businesses. If you're going to program your CI with a web admini…

If we were hypothetically "too big" for TeamCity, with scaling difficulties all over, do you have (or have heard) any recommendations? I hear the biggest companies all roll their own, but is there anything between TeamCity and Google-scale?

Jenkins + generated jobs (i.e. jenkins-job-dsl or the new Pipeline DSL), and keep as much as the build configuration and logic in your project where it belongs. The configuration that lives on the CI server should be pretty minimal.

We have a custom wrapper around the jenkins-job-dsl that encodes our conventions and templates to generate several hundred jobs, and it works very well for our medium-scale instance.

Re: Jenkins 2.0 Beta

#89

Post by abayer »

ecnahc515 wrote: post #80
oblio wrote: post #62

Earlier quoted context omitted.

Then this should be a life saver for this scenario: https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin Jenkins has a ton of issues but with a bit of careful plugin selection it provides a ton of bang for your buck.

The new integrated DSL to replace that plugin is going to be great. Unfortunately, managing jenkins plugins themselves via config management/orchestration is still surprisingly difficult.

fwiw, this is very much on the roadmap - https://issues.jenkins-ci.org/browse/JENKINS-31094 - don't know when it'll land, but it will be done. =)

Re: Jenkins 2.0 Beta

#90

Post by genericpenguin »

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…

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 recommending it as a solution atm). Maybe I'm missing something, but it seems like a lot of complexity is added to the deployment/worker management system that is pretty much a requirement if you want slaves external to the master. Is there a way to not have to use BOSH (BOSH Lite still tries to shoehorn things I don't want/need) to run Concourse builds? We use a combination of VMWare/KVM VMs, LXC and Docker containers for our builds and we have our own working deployment system (Puppet manages all our state successfully for VMs and LXC containers) which I would like to integrate with Concourse. I really hope I'm missing something because what I saw when I tried out Concourse for a week, made me swoon.
Post reply on HN