Show HN: UI improvements for Jenkins | Hacker News Reader

Show HN: UI improvements for Jenkins

github.com

92 pointskevinburke76 comments

The skin is really nice. I'm a real jenkins hater (one of the reasons I started https://circleci.com) and while I think this makes Jenkins look really nice, I also think a superficial change like this doesn't really solve the major usability problems that jenkins has.

There's a huge amount wrong with Jenkins. My major gripe is that the world today has moved very much to "convention over configuration", also known as "usability". But Jenkins is firmly stuck behind. It's not wrong to say that nothing works out of the box, and you have to configure every little thing. CircleCI customers have told me they've literally spent 2 days configuring a jenkins box to even get it working, and are glad to be rid of it.

One example of jenkins' backwardness is a post from the Jenkins lead last week: https://news.ycombinator.com/item?id=6434194. Actual quote: "The literate plugin adds an Action to all Free-style projects that allows exporting these XML configuration snippets in a .zip file for unpacking into your project's source control."

I don't mean to hate on this, just jenkins. This design is a real improvement, one that Jenkins has been unable to do in the entire 10 years it's been in existence.

[disclaimer: obviously I have a massive massive bias against jenkins, as part of CircleCIs mission is vanquish it and its awful usability]

Fair enough to advocate for your project, which I btw find it very nice.

However, xml configuration is really a weak argument. It is very rare that anyone needs to touch the XML files. In fact, when someone touches those files is normally due to either a very extreme case or more commonly lack of interest in learning how the admin UI works. Jenkins lets you manage absolutely everything from the UI, from the very beginning, which is pretty convention-over-configurationish. Also Jenkins' changes control system lets you track and diff every change very quickly.

Fair. My real gripe with jenkins is the UI configuration - the XML is a bit of a sideshow. I'll restructure my post slightly, thanks.

You can track changes in Jenkins configurations?

Actually I was wrong on that one. I took for granted that you could track changes because we have a nice "Job Config History" menu option. But that is actually the job config history plugin ( https://wiki.jenkins-ci.org/display/JENKINS/JobConfigHistory... )

So, I step back on saying Jenkins lets you track main changes history. That has to be done manually I guess.

This plugin is actually really nice.

Thanks, this will help. :)

I find Jenkins UI too cluttered with a lot of stuff being hidden by default behind the "Advanced" buttons. So I stopped using Jenkins UI and migrate all my job definitions to YAML file in my source code repo. I use OpenStack Jenkins-job-builder to generate job.

Here is the list of different tools, that can be used to automate Jenkins: https://gist.github.com/lechat/6666099

> or more commonly lack of interest in learning how the admin UI works.

If this is even possible, the admin UI is not usable enough. "Man, I wouldn't have to use this ridiculous XML configuration system, if only I had the patience to slog through this UI. Alas..."

CI sucks... in big companies it sucks more. The unruly XML configs are a small part of the problem.

Taking two days though? Fire the engineer(s) behind the initiative. (I assume this is a one-sided sales pitch though.)

You guys have clearly hired a baller good UX/UI person and have an amazing roster of clients. Wish you all the success in the world!

Two days actually makes sense. Let's say you already have a machine, and haven't set up jenkins before. You need to install ubuntu, install jenkins, and then start to configure and figure it out as you go. Its not use friendly, so I would expect this to take most of the day.

That's without installing the databases, queues, etc, that you need. In all likelyhood, you wont have this in chef (your production box doesn't run postgres or redis or rabbit), so you're going from scratch. All it takes is one pesky configuration thing you can't figure out to have it take your entire day.

And heaven forbid if you haven't got a few years of linux admining under your belt already, in which case you can write off the rest of the week.

And don't forget to document it so that it is repeatable and then cleanup the documentation when you are done with all the configs that didn't work.

Shouldn't there be a reusable Ansible-Docker thingy somewhere?

It's not configuring jenkins that's the problem. It's all scripts it requires, build, testing, packing, deployment scripts and whatever else you want to automate.

In general trying to automate things, brings all the workflow problems out to forefront to be fixed. It makes thinking clearer.

Depending on your needs, Bitnami [0] and TurnKey Linux [1] offer preconfigured batteries-included VMs (among other options) that might lower the barrier to entry. (I'm not affiliated with either, but have enjoyed using Bitnami's stacks.)

In particular, I have found Bitnami's Jenkins stack to be helpful for quickly spinning up a prototype and focusing on Jenkins rather than than installing+configuring databases and other stuff. I think it took me about an hour to be up and running with Bitnami's Jenkins VM, including download and provisioning time. It then took me quite a bit longer to coax Jenkins into building my stuff correctly.

Installing and configuring databases and other subsystems may eventually be necessary depending on scale. For my prototyping and learning needs, I've greatly benefited by working with self-contained VMs like Bitnami's. It's an option to consider, at least.

[0] http://bitnami.com/stack/jenkins

[1] http://www.turnkeylinux.org/jenkins

"CI sucks... in big companies it sucks more. The unruly XML configs are a small part of the problem."

That has nothing to do with CI. CI is a workflow, not an implementation.

Having used CircleCI for a trial period, I can say Jenkins is definitely the way to go. CI on a PaaS is a bit of a black box, and when things go wrong you will suffer. The only real thing CircleCI does is put some pretty CSS around what Jenkins already does. Nice try though...

When was your trial? Happy to hear about the suffering and what we could do better there.

We have actually spent a lot of time trying to reduce the pain and suffering from CI. Of course, you can't please everybody: trying to do that gets you Jenkins. Rather, we try to make a wonderful experience for web apps running on Linux.

Some examples of this: scaling your CI to run more than one build at the same time is tough on Jenkins, trivial on Circle. Same with splitting long builds over multiple machines. Doing either of these on jenkins is a massive pain, and most of our converts from jenkins come over at that point in trying to scale it.

Another example is that many projects will just work out of the box, with no configuration: Ruby, node and python projects in particular (also Go, scala and clojure and a subset of Java projects). But when you do need to configure, we allow you configure a very large amount. How does that differ from jenkins? Well, we try to make that configuration as simple as possible, while still providing you with as much power as you need. See some detail in https://circleci.com/docs/configuration

Lastly, in terms of preventing suffering, we have some really cool features around debugging, such as being able to SSH into our build VMs, and fantastic customer service, manned by engineers (my day is Monday, feel free to say hi: sayhi [at] circleci.com).

Do you support SVN? If not, why not?

Don't mean to hijack the thread, but since you dropped in the shameless plug, I got a question: are you considering allowing repos outside of GitHub? I know it sounds like heresy here on HN, but f.ex. I often don't host my commercial projects there, and both Circle and Travis accept only GitHub. I mean, what's the difference where the git repo is hosted (other than UX)?

Yea, I checked out CircleCI back when the demo was making the rounds. Cool looking, but I don't use GitHub so it's kind of useless for me. I keep it on my "keep an eye on it" list, and would switch in a heartbeat if it

1. Supported non-GitHub hosted repos 2. Supported more languages (Objective-C, C++, etc) 3. Supported SVN

I believe your svn needs can be worked around with some git-svn, provided they dropped the github lock-in.

Its about focus, which I believe is essential for both great products and successful startups. By focussing on GitHub only (we also focus pretty much on web apps running on Linux) we are able to make a great experience with limited resources. If we had said we'll also support svn and objc and windows and iphone and embedded systems, we'd be all over the place.

I consider it like Heroku vs Amazon. You can do anything with Amazon (like on Jenkins), but with Heroku it just works (like on Circle).

I don't get it, heroku is not a github plugin, I don't see how providing a clone url on a different domain would make you unfocused. But it's your business, so good luck anyway.

The Status API, how we clone quickly, the entire signup workflow are all built around Github. We have special logic for github downtime, retries, handling 3rd party repos, collaborators, etc. For example, we dont have usernames or passwords or password resets for Circle, we just have github oauth. We don't have teams, we just mirror the github permission model. We don't verify your email: github does it.

Most importantly, when you sign up, there's a great flow. You give us oauth permission, and pick a repo (we have a list because Github) and then we can have you running tests in seconds. We automatically fiddle with Github to make that work (you dont need to add post-commit hooks or ssh keys, it just works).

>>Some examples of this: scaling your CI to run more than one build at the same time is tough on Jenkins, trivial on Circle

That is not true. In Jenkins you just check "concurrent builds" in your job configuration and that's all.

As a current user of CircleCI, and as someone who set up Jenkins for general consumption at my last company, I have to echo your sentiment. With CircleCI, we have been left in the dark for more time than I care to think about due to completely oddworld (and sometimes sporadic) failures. Jenkins took me less than a day to set up (as someone who had never set it up before), and while it wasn't all smooth sailing, everyone was capable of diagnosing problems that we encountered.

To be fair to both Circle and Jenkins, between Github, Heroku and/or <insert other virtual services here>, there are a lot of 'black boxes' that have to work in concert (for us, and probably for many others out here). As the pin that ties the deployment cycle together, CI tends to draw on a lot of hate (warranted or not) from engineers trying to get their code out of the door.

I find that I am happier when I can get my hands dirty and help myself when things go awry. Software is all fun and games until a black box is standing between you and deployment.

2 days to configure jenkins? Yeaaaaahh suuureee...

Why doesn't Hacker News just delete obvious spam? I mean really whats the difference from this post to "buy cheap here, watches discount outlet..." Its more coherent, but other than that ;) Or how about giving it another background color and label it clearly as advertisement in case op payed not to get spamfiltered.

Not very obvious. The first time I met Jenkins, I think, it took about a day (or maybe even more) until I stopped tinkering the knobs.

Most of the time was spent not configuring it (I guess it took maybe a pair of hours or about so), but experimenting around and reading about features/use cases/examples to understand what I can do and what I can't.

That seems more than a little dishonest.

Installing jenkins and adding a job that will work immediately is a matter of minutes and doesn't require you to touch any configuration file at all.

Definitely much quicker than figuring out the pricing and limitations of CircleCI.

A matter of minutes? Now who's being dishonest.

Unless you already have experience setting up a JVM stack, it's going to take you many hours.

Not really. It has a Debian/Ubuntu repository. A couple of commands and then it's literally "sudo apt-get install jenkins"

On any recent distro the following command (or equivalent) will leave you with a fully functional jenkins on port 8080:

   apt-get install jenkins

From there you open the web interface and click on 'New job'...

How you'd spend 'many hours' on that is beyond me.

The whole "hours of pain thing", first begins when you press "New job". I set up my first Jenkins build server a week ago and I spent about 10 hours googling cryptic error messages, when trying to configure the build.

So first it begins with the installation, now it begins after installation...

I have a strong feeling someone is trolling here.

Can you paste some of these 'cryptic error messages' that you were getting?

Those are two different people...

Dude these are your own words: "Installing jenkins and adding a job".

Installing Java is a matter of minutes and you probably already have it in your system.

Then you have many platform specific packages or you can just download the war and run "java -jar jenkins.war".

I don't know why you hate Jenkins so much but from my experience, Jenkins is better than a lot of the OSS from the installation / maintenance point of view, e.g. you can perform upgrade, restart, install plugins and most of the other tasks just using the web ui, and since it is Java, you only need a JVM and don't need to deal with stuffs like rvm, gems, passenger & nginx found in some rail projects like redmine.

I'm another competitor in this space -- in fact more a competitor to Jenkins than CircleCI in that we don't offer CI-as-a-service (if anyone's interested the details are in my profile).

I think you're unfair to Jenkins in a couple of ways:

1) It's not as hard to set up as you make out. If you want to see what it's really like for nothing to work out of the box then head to the pre-Jenkins (then Hudson) era when CruiseControl was king (and I mean no disrespect to CC, it was a groundbreaking project). I agree, though, that the overall UX leaves plenty to be desired, and indeed this is one way we compete with Jenkins.

2) The strength of Jenkins is support for a huge range of environments and tools, with contributions in the small from a massive user base. Part of the trade off for this flexibility is some extra complexity.

I gather CircleCI approaches this space from a different angle, by narrowing focus thus making a streamlined UX a lot easier. That's a fine approach, and I wish you great luck, but it's not a way to "vanquish" Jenkins because you won't be able to satisfy most of the Jenkins user base.

Our approach is somewhere in between, and the balance is our greatest challenge. We've spent a lot of effort focused on ease of setup, and even more on ease of ongoing maintenance (especially for large build farms). I don't expect we'll ever compete with Jenkins on pure flexibility, rather I think there is room for many competitors in this space. After all, everyone should be into CI!

Yo, I love what you guys are doing - I even interviewed with ya'll last spring - but you're overdissing Jenkins here. I can get a basic job running in a basic Jenkins instance in well under 30 minutes, for an already live Linux server w/ JRE. I don't have to configure hardly anything except for the job.

Notus Bene: Mind you, after you need to do super complicated things & especially fuss with some varieties Windows auth, Jenkins gets complicated.

Jenkins and many other tools are designed by developers, there needs to be a word for that... we just call it "developer design" - functional but ugly.

Jenkins is especially bad with the transparent logos overlapping the butler image. A lot of developer designed tools have a simplicity like Hacker News or infinite possible customizations like X windows. Jenkins has neither of these attributes and often just seems painful to use

In a lot of cases it's only functional in the sense that it performs a function. To me functional but ugly implies a certain sort of delusion that while it might look ugly, it is really efficient to interact with, so therefore, it doesn't need to look nice. This is often not the case though. A lot of these developer designed interfaces end up being confusing, hard to navigate, and ugly.

To be fair they're working with a completely different set of constraints than this is - this is close to the Delta ticket redesign project if you could also use it for your delta ticket. They have to support every browser, every language, every platform, every ARIA recommendation, and make sure that everything is open source compliant, which is fairly tricky.

> Removes a lot of the useless icons

The screenshot implies that it's removed all the icons - are icons universally considered useless now? I know I'm a sample of one, but I've always found the console icon to get "console output", the big red button for "delete", etc to be useful and unobtrusive...

> The fonts are bigger. Way bigger. > More spacing in between list items. > Text inputs are friendlier, bigger

For people using jenkins on their phones? :S I'm using it on a 1080p monitor, and even then I sometimes use my browser's zoom feature to zoom out so that I can fit more information on screen...

I'm all for UI improvements, but this just seems like "replace things with bootstrap, because everything has to be like bootstrap now" :(

11px is a pretty small default, below the recommended size. For links it also means a small target to click on.

There's some context about icons here: http://jonoscript.wordpress.com/2012/04/26/gmail-designer-ar...

If they are universally acknowledgeable (a big red X, a red dot, a green dot) then yeah they make sense, otherwise they just lead to confusion about what they do. In this case I didn't think they were adding anything to the left hand marker so I removed them.

Thanks for starting this. As a daily Jenkins user, I'm convinced there's a huge room for improvement re: UX. However, I think the icon removal is misguided. Default Jenkins icons are dated and probably too bold, but we shouldn't get rid of icons entirely. Menus change a lot in Jenkins (depending on context and rights). Having icons next to links makes it easier to spot the right action or menu item by scanning, instead of having to read it all. In my opinion, the link you cite does not at all justify removing icons. It says that having only icons (additionally, unclear ones) is an issue, with which I couldn't agree more.

To add more feedback: - I love the new console output. - I think the font-size is better. - I like the more-roomy build history better. - I think you could replace the dated build-status and build-weather-report icons to something more modern and better-looking

I'm already using it (just customized it a bit to match the colors at work, and reintroduced the images).

The UI is now nicer, especially the black background output and larger inputs.

Thank you for your work

There's a lot of hate bouncing around here for Jenkins. Can we stop for a moment and remember what it meant to set up a build system before Jenkins was around? Sure, it's not rocket science, but Jenkins made things quite a lot easier and made continue integration actually possible to think about for many shops. It's no small feat that they managed to do this for n revision control systems * m languages with associated build systems and testing frameworks * q random options and make it still mostly work.

Jenkins moved the minimum acceptable level of automation, for the industry, up quite a lot farther than it used to be. Say what you will but remember its impact, and that the guy who made it is quite possibly reading this thread.

I opted to use TeamCity for all my CI exactly because of the UI. It's not perfect either, but I think it is vastly superior. Bigger install, though and relies on a JVM.

is it free?

The Professional license is free and gives 20 active build configurations & 3 simultaneous builds. I install extra instances if I need more.

You might also want to look at Go[1] from ThoughtWorks* - the UI and first class Pipeline support is it +ves.

[1] - http://www.thoughtworks.com/products/go-continuous-delivery/...

* - I work for ThoughtWorks, but not associated with the Go team, and use Teamcity and Jenkins more than Go.

Superior? Depends on what you're building. Using TeamCity to set up builds for iOS is a royal pain in the ass, and their OS X support in general is greatly lacking. I've had to create a whole ecosystem of shell scripts just to produce signed .ipa builds for QA -- which is kinda the point of purchasing a licence to a CI system to begin with.

I see that you've got green orbs. Or, more specifically, I don't. I saw a build history with yellow and red orbs but had a hunch and used assistive software to discover that they were actually green.

I don't really mind because I'll never put this on my boxes (I've never really minded that the jenkins UI is years behind design trends), but you may want to be aware of colorblindness when toting "UI improvements".

So thankful for the Chrome extension. Even more thankful to see some UI projects happening through Github. We use Jenkins every day around the office and I can't count the amount of times someone mentions just how... not pretty... or, worse, confusing the interface can be, especially moving out of jobs you normally focus in. It's a bunch of elements that make sense after a while of using it, but initially it's a bit much.

Jenkins has done a great job in getting continuous integration as a workflow into the hands of many developers.

But their usability is completely out of date and their current user base doesn't let them evolve to where they would need to be. Especially integration with PaaS services like Heroku should just be there from the start, but has never been a focus for the Jenkins community which still seems to be very on-premise based with all of their infrastructure.

More and more developers seem to be jumping on hosted solutions now (e.g. https://www.codeship.io where I am one of the founders)

Good job on having the typical non-biased flak-attack and also spamming your startup.

Somewhat off-topic, but if you're looking for a good OSS CI solution, you may want to check out Strider[1]. It has far fewer features then Jenkins, but it looks nice and is incredibly easy to deploy. If you want, you can just push straight to Heroku. Of course this leaves you somewhat restricted in what tools are available, but has worked well for me for simple Python and Node.js projects.

[1] https://github.com/Strider-CD/strider/

As for my personal tastes - and judging only by provided screenshots - I think the original looks better than redesign. Except for Courier New replacement to Consolas and console part, which, indeed, has to be white on black (or, better, light gray on black, white is for highlights), not the other way around. Probably that's the lack of primary navigation menu icons that I dislike the most.

This looks nice, a friend of mine made a nice simple dashboard showing jenkins build status if anyone is interested https://github.com/jackbot/jenkins-dashboard#screenshot

Chrome extension is awesome! Our grumpy sys admin will no bother updating our Jenkins.

Looks nice. But then Jenkins is an extremely low bar to jump. I've always considered it kind of hilariously bad and at this point it would be kind of sad to see it improve ... it just wouldn't feel like Jenkins any more!

> Jenkins is an extremely low bar to jump.

I'm pretty fond of Bamboo's default (only?) theme [1].

Although the focus on building Java software is undeniable, we build a bunch of C# projects on it just fine (with its built-in MSBuild and MSTest tasks).

Bamboo 5 brings "deployment projects" [2] which makes CI just that little bit easier.

I've also used Hudson (ages ago: prior to it being forked) and although it's not a fair comparison, Bamboo is miles ahead.

[1] https://www.atlassian.com/en/software/bamboo/overviewHero/im...

[2] https://confluence.atlassian.com/download/attachments/365658...

This looks really awesome. We use Jenkins heavily for deploying applications from build all the way through production.

I'll look into this and see what I can get out of it.

I'm curious why you would want a "build now" button on every page. Isn't it easy to configure Jenkins to build on every post-push webhook from GitHub?

That might be so. But not everyone uses GitHub, y'know?

But everyone uses some other version control system, isn't it? Set Jenkins job to poll you source code repository...

Sometimes I'm trying to improve a step, and want to test a quick change. Going from Build Configuration up to Build Overview to click on Run Build is slow and easy to forget, and I don't want to check something in just o trigger a build.

Plus, TeamCity has 'Run Now' on every build-related page.

We use jenkins and just yesterday I had changed the build process slightly so it also runs a different ant task post build without muddying our svn with empty commits,a perfectly acceptable reason to have a build now button .

Great work. I've thought about doing this before, but good for you for putting in the effort to make it work, instead of just thinking about it like I did.

Very nice!! I intend to implement this on our Jenkins instance this week.

Repo was starred in a heartbeat.

Screenshots?

will install this ASAP ..

Reply on news.ycombinator.com