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

61–70 of 157 posts

Re: Jenkins 2.0 Beta

#61

Post by mark242 »

ascotan wrote: post #52
mark242 wrote: post #22

Earlier quoted context omitted.

"Heaps in the 1-2 GB range are not uncommon." Is this really still a complaint in 2016? Your phone has that much RAM. Honestly if you're worried about Java heap size, spin up a t2.medium instead of a t2.small for your build pipeline. Running Jenkins on a Raspberry Pi is probably not a great idea if you're writing any serious application.

Actually it's becoming more of a complaint in 2016 with rise AWS instances that pay by the container size and with the rise of languages like go, etc. which have smaller runtime sizes and are more compatible with cloud computing environments like docker. The JVM adds something like 400MB to every layer of a docker container resulting in multi gigabyte containers. Additionally the memory requirements for running a JVM…

Don't run production code on a nano.

Don't run production code on a nano.

Don't run production code on a nano.

I don't care what language you're using, if you find yourself saying "well, I could run on a nano" just stop.

Re: Jenkins 2.0 Beta

#62

Post by oblio »

pswenson wrote: post #33
Alupis wrote: post #17

Earlier quoted context omitted.

> - 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.

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.

Re: Jenkins 2.0 Beta

#63

Post by seanp2k2 »

dominotw wrote: post #51
nod wrote: post #46

Earlier quoted context omitted.

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?

We use jenkins at medium scale. > 400 jobs, 20k-30k builds/day. Works just fine.

Jenkins works fine with dozens to hundreds of slaves per master, thousands of jobs, and tens of thousands of builds per day. Jenkins isn't perfect for everything, but it can be a very useful task runner. People have adapted it to do almost everything these days, from database maintenances to builds to restarting infrastructure. Given the almost unlimited triggering and reporting, you could use it to build many ETL apps as well (not saying that's a good idea).

As much as Jenkins sucks sometimes, it's what many big shops use for many things. There is tons of community around it. It works, it's battle-tested, and it's been that way for years. Anything else will have a hard time catching up for as many use-cases as Jenkins currently solves for people.

If you hate a part of it, fix it and open a PR :)

Re: Jenkins 2.0 Beta

#64

Post by oblio »

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…

Well...

Jenkins 2.0 will provide support for build chains via the pipeline plugin which will be included as a core plugin.

Access control can be configured quite nicely with the Role Strategy Plugin: https://wiki.jenkins-ci.org/display/JENKINS/Role+Strategy+Pl... + AD/LDAP integration.

Reporting automation is covered by the pipeline plugin. Custom reporting is quite easy to implement on top of Jenkins, its APIs cover almost everything you need.

Re: Jenkins 2.0 Beta

#65

Post by brown9-2 »

pswenson wrote: post #30
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.

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

You can do this today with the Job DSL plugin.

Re: Jenkins 2.0 Beta

#66

Post by oblio »

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…

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.

Re: Jenkins 2.0 Beta

#67

Post by mikehollinger »

wahnfrieden wrote: post #24
mikehollinger wrote: post #19

Earlier quoted context omitted.

Yeah, version control of Jenkins itself has always scared me. There seems to be a pattern that we go through. (in the beginning, there was light...) * Create a small, tight, single-purpose Jenkins job * Add a small tweak to it (repeat adding tweaks) (realize the Jenkins job now contains MANY different configurations options and the job itself is now a shell script in its own right) * Sweep the "job" into a shell scri…

We use Netflix's Job-DSL to keep Jenkins job configuration in source control (and to allow easier reuse than offered with job reuse plugins). https://github.com/jenkinsci/job-dsl-plugin

Apache Bigtop relies on this, and does a pretty spiffy job of configuring itself out of the box this way.

Will look more closely...

Re: Jenkins 2.0 Beta

#68

Post by oakhaven »

Alupis wrote: post #6
oakhaven wrote: post #4

I came here to write sth like "still in Java... :/" but I can't even check it, the site seems to be hugged to death.

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

In my opinion

Using XML is always wrong. If you want to automate Jenkins setup with sth like Docker or Ansible, you have to touch the configuration, and that means dealing with XML, which makes me cry. There are many ways to do configuration reasonably. Not so related to Java but hand in hand, as somebody else put it: "Java is a DSL to convert large XML files to stack traces".

It's impossible to debug, and its plugins are impossible to debug. If it would be in a scripting language, you could see what's going on easily, maybe print debug messages, and wouldn't have to clone-edit-compile-(deploy)-run in order to debug.

When some Jenkins plugin doesn't work out-of-the box, I straight up give up on it, because I know there's no simple way to interactively dive into the code. Based on my experience, I really tried. YMMV.

Re: Jenkins 2.0 Beta

#69

Post by oakhaven »

mark242 wrote: post #22
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…

"Heaps in the 1-2 GB range are not uncommon." Is this really still a complaint in 2016? Your phone has that much RAM. Honestly if you're worried about Java heap size, spin up a t2.medium instead of a t2.small for your build pipeline. Running Jenkins on a Raspberry Pi is probably not a great idea if you're writing any serious application.

In the simplest case, Jenkins is just polling and cloning git repos, and then spawning some tests. This plus config parsing and web frontend is not a 1GB RAM job.

Re: Jenkins 2.0 Beta

#70

Post by solipsism »

christop wrote: post #48
solipsism wrote: post #41

Earlier quoted context omitted.

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.

And if I change where I keep my pipeline config, I have to commit a change to the project so it grabs it from the new place? Or pass it in as a parameter, so you need to know ahead of time what parameters the DSL will be expecting?

Come on now, we don't need to go to these contortions just to avoid saying that Jenkins is doing it wrong.

Post reply on HN