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

41–50 of 157 posts

Re: Jenkins 2.0 Beta

#41

Post by solipsism »

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.

the integration of a "Jenkinsfile" which allows configuration of jobs via a proprietary DSL

This makes no sense to me. Only how my project is built should be checked into the project's repo, not the whole CI/CD deployment pipeline! If I start deploying to Azure instead of AWS I need to commit that change to my project? It's nonsense.

Re: Jenkins 2.0 Beta

#42

Post by yamitty11 »

jquast wrote: post #32
radicalbyte wrote: post #29

Earlier quoted context omitted.

If you're putting lots of logic into ANY CI server you're doing it wrong! Script your build so that you can run it with a single command on any build server or any developer machine. Then have the build server invoke said scripts (with arguments for any build-server specific paths etc). Having spent a week fixing problems with inter-plugin dependencies I do agree with your point - Jenkins just isn't very good, like a…

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

Re: Jenkins 2.0 Beta

#43

Post by ABS »

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…

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 advanced way GoCD manages to tackle the diamond dependency problem (aka the Fan-In functionality).

Totally agree with you re pipeline as a first class citizen: I wrote this back in 2014 so it's kinda old now and surely Jenkins got better but I think it still applies by and large: https://highops.com/insights/continuous-delivery-pipelines-g...

Re: Jenkins 2.0 Beta

#44

Post by xvilka »

Jenkins by itself is eating too much memory on our buildservers, which can be used more wisely. Using compiled language could help that - e.g. Drone.io CI written in Go: https://drone.io/

You can find it's sources here: https://github.com/drone/drone

I just hope it would be able to work without docker, like jenkins.

Re: Jenkins 2.0 Beta

#45

Post by yamitty11 »

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…

Almost all of what you said here is totally wrong.

>What is interesting is that Jenkins has a DSL but that this is not part of the repository.

Netflix job dsl plugin, Jenkinsfile pipleline, dotci all of these let you put a .travis.yml like file in your repo.

>But the plugins have access deep into the Jenkins internals, preventing a rewrite of core functionality.

Plugins don't have deep access to jenkins internals they use clearly defined "extension points" .

I know you are trying to plug gitlab but 'our stuff is better because we don't allow plugins' is not exactly a plus. Jenkins is so popular because it can customized via plugins to wide range of use cases.

Re: Jenkins 2.0 Beta

#46

Post by nod »

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?

Re: Jenkins 2.0 Beta

#47

Post by hueving »

ChristianBundy wrote: post #34
Alupis wrote: post #25

Earlier quoted context omitted.

Take a look at the Usability Section[1] Looks like a massive facelift, and lots of work done to make things more intuitive, faster, and more pleasing to the eye. [1] https://jenkins.io/2.0/#ux

Unfortunately, the new design still looks almost a decade old.

So does hackernews. If it actually addresses the usability problems, it doesn't matter how 'old' it looks.

Re: Jenkins 2.0 Beta

#48

Post by christop »

solipsism wrote: post #41
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.

the integration of a "Jenkinsfile" which allows configuration of jobs via a proprietary DSL This makes no sense to me. Only how my project is built should be checked into the project's repo, not the whole CI/CD deployment pipeline! If I start deploying to Azure instead of AWS I need to commit that change to my project? It's nonsense.

The DSL can pull in other scripts from elsewhere, so you could just have a stub Jenkinsfile in your project, with the bulk of the pipeline config version-controlled in another repo.

Re: Jenkins 2.0 Beta

#49

Post by wmfiv »

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?

What is too big? Too many concurrent jobs? We found the integration with AWS to autolaunch workers to be quite easy to setup.

Re: Jenkins 2.0 Beta

#50

Post by Macha »

solipsism wrote: post #41
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.

the integration of a "Jenkinsfile" which allows configuration of jobs via a proprietary DSL This makes no sense to me. Only how my project is built should be checked into the project's repo, not the whole CI/CD deployment pipeline! If I start deploying to Azure instead of AWS I need to commit that change to my project? It's nonsense.

We use the pipeline plugin in my job and we use a seperate repo for pretty much the same reason. It's not a detail that's really part of the application (do you keep your chef cookbooks in the same repo?) and not only that but we use the same scripts across multiple apps.
Post reply on HN