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

31–40 of 157 posts

Re: Jenkins 2.0 Beta

#31

Post by sytse »

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 hard to extend when you introduce new functionality and when you push an old branch it might not work anymore. I think that the model that Travis CI pioneered clearly wins.

I'm torn on the plugins. One one hand it is great to be able to plug so much in. But the plugins have access deep into the Jenkins internals, preventing a rewrite of core functionality. Our idea is: "Because GitLab is open source the enhancements can become part of the codebase instead of being external. This ensures the automated tests for all functionality are continually run, ensuring that plugins always work. It also ensures GitLab can continue to evolve with it’s plugins instead of being bound to a plugin API that is hard to change and that resists refactoring. This ensures we have many years of quality code and great monthly releases ahead of us." https://about.gitlab.com/direction/#vision

Re: Jenkins 2.0 Beta

#32

Post by jquast »

radicalbyte wrote: post #29
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 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 it catch up to anywhere near TeamCity, even Bamboo in user or developer UX.

Re: Jenkins 2.0 Beta

#33

Post by pswenson »

Alupis wrote: post #17
FooBarWidget wrote: post #11

Earlier quoted context omitted.

Typical issues surrounding Java projects: - High startup time. Anything bigger than a hello world takes seconds, more typically tens of seconds, to start. My Jenkins setup takes 3 or 4 minutes before it is fully initialized. Even starting the JVM in client mode doesn't help much. I know, it's a server, and startup time doesn't matter once it's running, but it feels annoying. - High memory usage. Heaps in the 1-2 GB r…

> - High startup time. This is really not a problem. If you're starting and stopping your Jenkins often, you're really doing it wrong. Jenkins is a server, and really should only get restarted when there's been an update. Not to mention, other large servers that are not Java still take time to startup... there's a lot going on during initialization. > - High memory usage. Perhaps more of an issue for some, but again,…

the config is a huge problem, not just because of XML files. Jenkins (pre 2.0 at least) job configs have huge problems with config drift and doesn't play well with configuration management tools.

Trying to automate jenkins job configurations requires using the terrible job config xml format and a poorly designed rest API which breaks all the time when you add in a plugin or plugins get upgraded.

Re: Jenkins 2.0 Beta

#34

Post by ChristianBundy »

Alupis wrote: post #25
smegel wrote: post #18

If there was ever a webpage that needed a facelift, it would be Jenkins, so hopefully this is not just a backend rewrite.

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.

Re: Jenkins 2.0 Beta

#35

Post by zzzeek »

mschuster91 wrote: post #12

As the website got HN'd, a question: does Jenkins support now pass-through of parameters in pre/post build actions to other jobs? Background: I have "deploy frontend" and "deploy backend" job, both of which need to invalidate some layers of caching, and a job parameter that specifies the environment (it's the docroot). For now I have a metric shitload of shared code between the jobs as there is no way to move the cac…

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

Re: Jenkins 2.0 Beta

#36

Post by Eduard »

I hope Jenkins 2 will fix Jenkins 1's tendency for unclear and ambiguous user interfaces. Many configuration input fields have weird names, and their explanation fields can confuse me even more, and when using plugins, the whole configuration layout can quickly become a mess - Jenkins 1 often gives me the feeling of a mighty but hard-to-use Japanese pro tool lost in translation.

Re: Jenkins 2.0 Beta

#37

Post by jowiar »

bb0wn wrote: post #8

Very exciting -- a new major version of Jenkins has been a long time coming. > "Jenkins 2.0 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 once 2.0 is released." Skeptical, but optimistic about this claim. I hope that the Jenkins configuration format is something that can be manipulated more easily in the new version.

I'll believe it when I see it -- the Jenkins ecosystem is one of the worst offenders I've worked in with regards to things getting arbitrarily broken by a point release. I shudder to think what a major release will do.

Re: Jenkins 2.0 Beta

#38

Post by terminado »

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…

Jenkins compiles jars with Apache Ant, Maven, and checks code out from all the relevant SCMs, which, if you don't need more than that, works perfectly.

Also, arbitrary shell scripts, (as usual) provide duct tape for everything else as needed.

Re: Jenkins 2.0 Beta

#39

Post by dominotw »

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 you have a strong developer team, I would suggest using something like python buildbot and programming your CI end-end in a single unified language, much better than shoe-horning plugins and groovy code inside your jenkins textarea fields!

This is obscenely bad advice. We run thousands of builds/day and none of the configuration is maintained inside jenkins. All of our job configurations resides in repository alongside all the code.

Re: Jenkins 2.0 Beta

#40

Post by dmytroi »

FooBarWidget wrote: post #11
Alupis wrote: post #6

Earlier quoted context omitted.

> I came here to write sth like "still in Java... :/" And the problem with that is...?

Typical issues surrounding Java projects: - High startup time. Anything bigger than a hello world takes seconds, more typically tens of seconds, to start. My Jenkins setup takes 3 or 4 minutes before it is fully initialized. Even starting the JVM in client mode doesn't help much. I know, it's a server, and startup time doesn't matter once it's running, but it feels annoying. - High memory usage. Heaps in the 1-2 GB r…

I would agree on some of your points : few minutes initialization times and 1-2 GB heaps may sound not that bad, and when we are talking about product that just provides a fancy, over engineered way to run bunch of shell scripts (considering jenkins doesn't integrate sandboxing from the box) ... honestly there is no excuse to spend 2 gigs of ram just to run shell scripts with web UI. It would be much better in a long term to improve energy/resource efficiency of software like this, just to make it more sustainable and reliable.

Edit: configuration-as-code feature is available in jenkins 1.x with job dsl plugin [1], I'm using it at work, because managing 50+ jobs by hand was just insane. Nowadays we just have few dsl files :)

[1] https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin

Post reply on HN