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.
And the problem with that is...?
- 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 range are not uncommon. This can probably be tweaked but as a user who is not a Java expert, figuring out how to do this (and figuring out what value is safe) is frustrating.
- XML configuration files. XML was hip in 2004 but these days it is frowned upon and users generally don't like it. This is technically not Java's fault (and I'm sure newer projects use something else) but it is something traditionally heavily associated with Java projects.
- Non-Unixy feel. Lots of things just behave like they're not really native.
1. High startup time is amortised over long run times. Jenkins is a general CI server, not an interactive build tool.
2. High memory usage is true, though again tolerable given the role and importance Jenkins will assume in any sane project.
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, Jenkins is a build server, and should be on it's own hardware/vm, with it's own dedicated resources. If you're trying to squeeze by with 1GB of ram, you can, but you should expect the obvious results. The more complicated your builds, the more resources they're consume. Compiling GCC usually takes 1-2GB ram by itself. I don't consider this a problem.
> - XML configuration files.
If you're using Jenkins properly, you should not have to interact with any config files. Sure, if you're running it behind Tomcat or something, you'll need to dip into the configs, but not liking Jenkins because it has XML config files is shallow and superficial, in my opinion.
> - Non-Unixy feel. Lots of things just behave like they're not really native.
I'm not sure what to expect from a deliberately cross-platform system. Of course it's not "native Unix-like". But neither is any software written to support OS's that are not Unix-like. And again, you manage and use Jenkins from a web interface, so if you're on the command line, you're doing it wrong. (as an aside, Jenkins has native support for running shell scripts, which I make heavy use of... can't get any more unix-like than that).
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.
Jenkins has a ton of issues but with a bit of careful plugin selection it provides a ton of bang for your buck.
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.
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.
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.
Perhaps this is the "writing on the wall" that containers aren't what you should be using to deploy your app.
Just because it's the "latest craze" doesn't mean it's the best solution for the task at hand.
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
Oh, no! Seconds? Like five? Seven? For a process that you start less than once a day? Unacceptable.
> High memory usage. Heaps in the 1-2 GB range are not uncommon.
So... what? Spend an additional $30 on your build server and add 8Gb to it. Problem solved.
> - XML configuration files.
XML is fine. As opposed to Groovy, IDE's do a great job at offering auto-completion on it. But if Groovy is your bag, you can use that too.
> - Non-Unixy feel.
I have no idea what that means and I've been using UNIX for about thirty years now.
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.