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

51–60 of 157 posts

Re: Jenkins 2.0 Beta

#51

Post by dominotw »

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?

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

Works just fine.

Re: Jenkins 2.0 Beta

#52

Post by ascotan »

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.

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 put you immediately into the t2.medium range which will cost you 4X cost over a t2.nano for simply choosing to run Java instead of something with a smaller runtime footprint.

Re: Jenkins 2.0 Beta

#53

Post by snockerton »

zwischenzug wrote: post #2

I wrote these posts recently about stateless Jenkins deployments: https://zwischenzugs.wordpress.com/2016/01/24/ci-as-code-sta... https://zwischenzugs.wordpress.com/2016/01/30/ci-as-code-par... https://zwischenzugs.wordpress.com/2016/02/25/922/ Does anyone know if any effort has been put in to make Jenkins more 'programmable' in 2.0? I had a quick look at the bumph recently but couldn't see anything pertinent.

I agree that the lack of an easy, declarative deployment capability is one of Jenkins' biggest flaws and doesn't get near enough attention.

Re: Jenkins 2.0 Beta

#54

Post by maxxxxx »

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…

We made the same mistake with Anthill Pro a long time ago. The plugins were of various quality and caused us a lot of headache.

Now our build and test suite is just a script each and it can pretty much on on any CI server.

Re: Jenkins 2.0 Beta

#55

Post by hidingfornow »

I've been tasked with implementing a large Jenkins deployment to support a ton of teams and I don't think I've hated a piece of software so much in such a long time. The past few years I've been using other CI systems like Circle and I totally forgot how much you have to fight Jenkins.

The UI is atrocious, job state is spread out among tons of crappy xml files, and the plugin system causes tons of headaches. If you're going to have a system that forces you to use the UI for the most part, rather than scripting up config files that I can load with some automation, at least make that UI nice to use.

Hopefully 2.0 is fixed up, but personally I'd never reach for Jenkins as a CI system if it wasn't part of a client's requirements.

Re: Jenkins 2.0 Beta

#56

Post by Pyppe »

xvilka wrote: post #44

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.

Jenkins too is built on top of a compiled language. Too bad it is JVM, which is a hog when it comes to memory... Point being that a "compiled language" is no guarantee of a low memory usage.

Re: Jenkins 2.0 Beta

#57

Post by Alupis »

hueving wrote: post #47
ChristianBundy wrote: post #34

Earlier quoted context omitted.

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.

Couldn't agree more. Jenkins is a tool - it doesn't need to look "uber modern", but it needs to be functional (which it is).

Re: Jenkins 2.0 Beta

#58

Post by PascalW »

mikehollinger wrote: post #19
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…

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…

At my work we're running all Jenkins jobs in Docker containers using some simple scripting [1].

Works really great. Jobs can run on any slave, no snowflakes, full CI config is versioned in the repo along with the code. Jenkins job only point to a single script and that's it.

[1] https://github.com/kabisa/jenkins-docker

Re: Jenkins 2.0 Beta

#59

Post by stephenconnolly »

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…

> build configuration is purely declarative and can be checked in with the project.

Seems like you are missing the point of pipeline and the Jenkinsfile concept, namely that the pipeline is part of the SCM.

Yes you can have the pipeline defined in the old-style text box in the job config, but that is intended to be used only while you develop the pipeline. Once you get it developed it gets checked in to source control.

Of course there are down sides to having the build instructions in source control, e.g. drive-by hack via Pull Request... granted this is nothing new... You can always do the drive by hack in a unit test... but it does take a little more work. In that regard having the Jenkinsfile in a text box (or better yet in a separate SCM) can be a useful protection (as can mandating that PRs use the target branch Jenkinsfile rather than the Jenkinsfile in the PR... again a feature in Jenkins pipelines)

For me the real advantage in pipeline is the organization folders support. You can tell Jenkins to scan all the repositories in your GitHub org and automatically create Jenkins jobs for any branches of any repositories that have a Jenkinsfile... PRs will automatically (subject to basic drive-by hack protection) be built and the commit will be tagged with the result.

So as with all things Jenkins, you have choices... we are providing some opinionated defaults (which is a change from the 1.x series)

> That said, this appears to be achieved by promoting the plugin into the default installation.

So the thing to remember is that the core of Jenkins is really better viewed as a platform. The plugins are really where functionality for Jenkins lives. I would expect to see more of the "current core" functionality get shipped out of core and into plugins. There is no reason why the Freestyle job type needs to remain in core. The advantage of having these functionalities outside of core is that we can be more reactive with regards to developing features.

> Further out, the Jenkins pipelines are tricky to do fan-out/fan-in with

I might have a different view on that claim, but hey I'm significantly biased.

OTOH my personal view is that for the 99% of jobs pipeline is overkill and literate is actually a better fit... but sadly most people don't seem to like the idea of actually making your source control have a README.md file with a - shock horror - "build" section that actually has the verbatim command required to build the software in source control (perhaps with an "environments" section that describes the build / test toolchains and environments)... I guess there's too many people who signed up to the mortgage-driven development manifesto [1] to actually want to leave a README file in source control explaining how to build and release the software!

Disclaimer: I created the weather report column and I am an active Jenkins developer

[1] https://refuctoring.wordpress.com/2011/01/13/the-mortgage-dr...

Re: Jenkins 2.0 Beta

#60

Post by gnoway »

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

We're using this as well, it's got warts but it's 100x better than authoring jobs in the web ui.
Post reply on HN