Blue Ocean: a new user experience for Jenkins | Hacker News Reader

Blue Ocean: a new user experience for Jenkins

jenkins.io

382 pointsArtemis2105 comments

My team and I designed Blue Ocean. We are really excited to get your feedback and suggestions. Ask me anything :)

First, let me say this looks amazing. Thanks for your work!

My biggest issue with Jenkins so far has been configuring complex jobs. The single configuration page just gets unwiedly fast, and important settings are often hidden by default.

Is there any work being done to make this easier as well?

Wow thanks for the complement - I'm chuffed!

There's a trend to move job configuration to a Jenkinsfile that's stored in a Git repository using Jenkins Pipeline. What used to be several jobs is now one Pipeline job config defined using this DSL https://jenkins.io/solutions/pipeline/

Today the pipeline visualization only works with this way of making jobs.

Now we realize this isn't for everyone and we are thinking about how to let users create Jenkins Pipelines through the UI without having to know the DSL (just like freestyle). We are also looking at making Pipeline easier for beginners too.

It probably doesn't need reiterating but not having Travis like config is my biggest issue with Jenkins as well.

While Pipeline looks awesome for sophisticated entities that have complex workflow it seems overly powerful for most I think that just have a lot of projects and configuration drift.

Pipeline unlike Travis Yaml is also not a declarative language. One of the advantages of using a declarative markup language that respects comments and spaces (cough XML) would be for the Web UI editor to intelligently edit the configuration files while respecting order, formatting and comments (right now I believe Jenkins XStreams so its just naive serialization).

Well you don't have to use the sophisticated features for a simple build.

Something like "node { sh './build.sh' }" will work fine.

But you can also build your own simplified syntax on top of Pipeline, e.g. I believe there is a prototype out there that will run Travis .yml scripts in a Pipeline job, and there are already plugins that simplify the Pipeline syntax, e.g. https://wiki.jenkins-ci.org/display/JENKINS/Simple+Build+For...

GoCD has XML configuration, if that's your kind of thing.

However, it turns out that tree-structured documents struggle to describe build graphs.

Good news is that there is a RFC in the Dev list proposing what you are asking for. I'm personally a big supporter of it http://jenkins-ci.361315.n4.nabble.com/RFC-Plumber-a-declara...

I wrote a Greasemonkey user script to always show any advanced, hidden settings in Jenkins.

I haven't tested it with the newer Jenkins 2.x versions, but you may want to try it to see if it helps.

https://www.opsfordevelopers.com/2015/03/jenkins-show-advanc...

Having some trouble getting it running: https://gist.github.com/boucher/1a9beb22ac3cbadf858a82f4db05...

Might be best to post to the Jenkins Dev mailing list - it's pretty alpha at the moment and there are bound to be rough edges. When it's more ready we will be pushing the plugin continuously to be update center :)

cd .. && mvn install

try that to build missing artifacts. It worked for me.

Great stuff! Working as designer on ownCloud where we use Jenkins it always felt outdated in the design department. Really good to see the improvements!

I also added the main contributors of the repository to the Open Source Design collective at https://github.com/opensourcedesign, more info at http://opensourcedesign.net – welcome! :)

Thank you! This is my first attempt at designing in open source and would love to chat about your experience if you've got some time - jdumay@cloudbees.com

I would like to ask you to please establish a new standard of NOT expecting all kind of config files in a project root directory - this is an annoying pestilence that has to stop and the Jenkins team could really help with that.

Please instead establish any kind of directory that is expected where all that project and tooling related meta files are kept, I would like to suggest a top level folder called "config" - but I really do not care, how this is called, as long as that top level config file annoyance will disappear forever.

I believe it might be acceptable to expect exactly one optional top level config file that might be called "configrc" that would contain only the path of that actual config path if this is not in a default place.

Thank you very much for your attention!

Well my original plan was that the default build instructions would be in a README.md file in the root of the source control as a verbatim block in the highest level heading containing the word "build"

If you needed any additional configuration for Jenkins specific instructions then that would be in a folder called ".jenkins"

Sadly, people did not embrace that project type... perhaps because it was given the nerdy name "literate" by a colleague of mine (who's name rhymes with Nichale Meale)

So dry, Stephen :)

Wow, thank you! Jenkins' appearance has been a major deterrent for me in the past.

It's not just an appearance change - we hope it's the way you use it too :)

Yes! This! A million times this!

I wished for a better Jenkins UI for so long I had given up hope. GitLab CI looked enticing, but after putting so much work into building a workflow that doesn't pollute my repos with environment specific data i'm right back at Jenkins.

Thanks for this, this will make it so much clearer to our POs where we stand without spending forever trying to push that info into Jira.

Have you looked at Concourse? I've only heard good things about it.

https://concourse.ci

Concourse is an amazing project, but sadly is very if you are trying to build around a docker type of workflow.

This[1] is for us a showstopper atm, so we are sticking to go.cd, although Jenkins seems to be improving a lot lately.

[1] https://github.com/concourse/concourse/issues/324

Thats interesting, GitLabs recent focus on the Docker workflow was one thing that irked me, since we won't be using Docker for the foreseeable future and I'm missing quite a few features to replace Jenkins completely. Has concourse good options for manual deployment?

It surely does. Also, their learning materials are great too. I found to be able to get a basic pipeline in a matter of a couple of hours.

If you don't have a docker heavy type of dev workflow, I think it is a great alternative. Totally worth checking it out.

Note that with GitLab CI, you can having anything run your build. It's just that we typically use Docker as an example and use it ourselves most intensely.

GitLab Runner (the 'slave' that runs your code), is just a Go binary, so it runs on anything you can run a Go binary on, which is pretty close to all major platforms.

Read more on Runner here: http://docs.gitlab.com/ce/ci/runners/README.html

And congrats to the Jenkins team! This looks amazing. A majority of our customers uses Jenkins. I'm sure they'll be excited to update.

My problem with Gitlab CI is that it's not as smart as Jenkins for Java projects. Jenkins beautifully handles maven multi-module projects and knows how to install the dependencies. All other CI-systems are available in Gitlab CE, but Jenkins integration is only available on Gitlab EE. That's the only reason my team doesn't use Gitlab as code repo.

You don't have to "use docker" to use Concourse. It runs docker images under the hood. It only becomes relevant when you define which container image to use to run things.

After a little while you'll realise you want something a bit different, at which point the docker-image resource that's supported by the Concourse team makes it embarrassingly easy. You just tell Concourse "yo, push to this image" and it does the rest.

Not yet, looks interesting though. But now i've got to checkout GoCD and Concourse instead of getting BlueOcean Running after updating Jenkins... all those choices, a blessing and a curse.

So glad you are excited! Let me know if you've got any feedback or suggestions.

Setting up a test instance right now. :)

Would love to hear how you are going with it. Perhaps post your thoughts to the user mailing list? https://jenkins.io/content/mailing-lists/

What do you mean with polluting repos with environments specific data? I hope we address your concern in GitLab CI with environments in GitLab 8.9 due June 22 and environment specific environmental variables in GitLab 8.10 due July 22.

I like the concept or pipeline, and I like that the definition can be checked in with the code, but :

* I don't like to couple the builds to a product

* Can I run the build locally? if something goes, how to I know if it's a bug in the pipeline script, the build server environment, or my code. I want reproducible builds.

Many teams opt to keep most of the logic of their process inside shell scripts or build tools (like Maven or Make). I'm not sure if there is any standard way of defining a Pipeline in the way I think you are asking that is tool agnostic.

Building locally is a good one and thats something I am thinking about in the long term.

The popular/recommended pattern for using Jenkins pipeline is to abstract the course grained build "steps" out to shell scripts and to use Jenkins pipeline to orchestrate the whole build process by running these steps at the right time (in parallel blocks etc), capturing human approval, making it all "durable" (tolerant of restarts) etc etc. If you find yourself putting lots of complex build logic into a pipeline script, then you're probably doing something wrong.

Doing it this way reduces the tie to the "product" and also means that you can easily test the individual self-contained steps outside of the product.

I can confirm that this is the pattern that folks on Concourse have moved towards as well.

When the CI system has high-level primitives for showing and organising build graphs, it makes sense to surface those instead of burying them inside a relatively opaque build tool.

I just wish they would have used this change to get rid of the weather icons ...

Interesting - why do you think they should be removed? I purposely kept them because they felt a very positive part of the Jenkins personality.

Just a matter of personal taste, they don't deliver the fast visual clues to me that simple red and green elements do in other CI systems like bamboo. From a distance, they look quite similar and that fails to give me a quick overview. From my experience, they are a very polarizing piece of UI design :)

They seem to have advantage for color blind people, no?

It's easier to disambiguate shapes than colors.

It's easier to disambiguate shapes and colors than just shapes or just colors -- something like a checkmark of one color, and an X of a different color.

FWIW We've got colored indicators that have appropriate iconography for these kinds of users.

I agree with you, and it's very easy to test. Print 15 mixed weather icons on one sheet of paper and 15 red/green/orange circles in another. Show them to test subjects for 1-2 seconds, and ask them to assess the situation. Now repeat the test, but showing the sheets from two meters away. Our brain is really good at color cues, and especially red = danger is deeply wired into us!

Red = danger doesn't seem to be so widespread outside the western world:

http://www.informationisbeautiful.net/visualizations/colours...

Possible, on the other hand traffic lights around the world have pretty much standardized on:

- green/blue: safe/go

- (optional) yellow: caution

- red: danger/stop

I don't know of any country where this convention is not in use.

As I learnt looking into the indicators the accessibility of traffic lights had a lot more to do with their vertical position than their colors. Can't use solid green, yellow and red if we want them to be understood by people with various forms of color blindness.

But you could make colorblind-friendly color schemes available through plugins instead of making a slightly more confusing option default.

Do you mean the weather icons? They are not the alternative to properly designed status indicators. Take a look at this https://jenkins.io/images/post-images/blueocean/pr-view.png

There's more about why and when we use them in my other comments.

Since the graph list "web sources" as a source, a cursory web search of "danger sign + region" reveals that red seems predominant in danger signs from:

- India: http://3.imimg.com/data3/II/GU/MY-762554/danger-signs-boards...

- Asia: http://cache4.asset-cache.net/gc/152921698-warning-these-sig...

- Africa: http://www.lifeloveandsugar.com/wp-content/uploads/2015/06/d...

- Middle East: http://cache3.asset-cache.net/gc/474346969-an-israeli-sign-i...

Look no further than mother nature, where bright colors often mean WARNING, I WILL MESS YOU UP. A few things to look up as examples:

* Rosary Pea

* Coral Snake

* Stag Beetle

* Jerusalem Cherry

* Phantasmal poison frog

* Strawberry poison dart frog

* Bittersweet nightshade berries

The Coral snake is debatable: it is so deadly that no animal can "learn" by getting bitten by it.

Instead one theory is that the mimicry is in reverse: the coral snake is mimicking the non-fatally venomous "false coral snake" which is also more numerous.

There are a variety of different theories on mimicry, and the science of the coral snake is still debated...

> Our brain is really good at color cues, and especially red = danger is deeply wired into us!

Except for the colourblind, who need additional ways for that information to be conveyed.

I like red/green schemes too, but there always needs to be other cues.

so that can be an option instead of crippling everyone else.

It's not an either/or proposition, designs can accommodate both.

The simplest approach is to add a symbol for failures, to distinguish them from successes. Other colours can be chosen for other statuses that the colour-blind can distinguish without additional symbols.

> It's not an either/or proposition, designs can accommodate both.

And Blue Ocean accommodates both. I think this would be a good blog post :)

For the record, this was by design

I wanted the status balls to be the primary focus. The weather icons should only be looked at when all the builds are blue. If they are too attention grabbing then you don't go fixing the red (didn't built) and yellow (tests failing) builds first

Well the weather icons do have meaning - they are a historical indicator of how successful your build or deployment process is. We show these along side the color accessible status indicators except on the non-personalized dashboard. On the dashboard, they indicate the historical health of your most important branch (e.g. Master)

Maybe it's me but I don't care about historical health. For my projects I only care about its current health because anything Jenkins builds is going to successfully build (when it doesn't it's a fluke because we shouldn't be checking in broken things).

Not sure if I'm in the minority here or not though but it actually bothers me if, say, I misconfigured something, build breaks, I fix it but now it's showing it's cloudy. It also took me way too long to realize that cloudy meant it built but failed in the past. I remember my first experience with Jenkins trying to figure out why the build was failing before realizing it wasn't failing and cloudy somehow meant it's good.

Noted - let me have a think about that. Might be worth having a look at the Personalised Dashboard in the blog again - that always shows the current status. Most screens refer either to the status of each branch or a specific job result. for the former a single status indicator wouldn't be appropriate. But what I'm hearing is the non-Personalised dashboard may be a point of contention.

I'd like to add a me too comment, but with another thought about historical build health. It's not that I don't find it useful, but I'd rather see it along with my other metrics rather than included in the UI of my CI tool. If Jenkins could be used as a Grafana source or were able to export build metrics to Influx/Prometheus, people could use existing tooling/dashboards to display build health over time while keeping the main Jenkins UI clean and focused on the current state of the builds.

Also, and I apologize if this is no longer how the Jenkins weather indicators work, but the last time I used Jenkins, the weather indicators were based on the number of failed builds, not the time the build wasn't green. For me, the number of failed builds is far less interesting than the amount of time that the build was failing. If a developer scrambles with three checkins in 15 minutes that attempt to fix the build and the third one succeeds, that's a better situation than a developer who takes a more measured approach that fixes the build four hours later on the first checkin. The first developer might have created a slightly messier commit history, but the second developer blocked the entire team for half a day. Taking the view that historical build information is really time series data would, to me, be much more insightful.

Team members should have sandbox builds available. Its maybe not true that the integration build is blocking everybody. I don't think this statistic is worthwhile. Just knowing its broken, and making steady progress on integrating a working system, is often enough.

You can expose some metrics via https://wiki.jenkins-ci.org/display/JENKINS/Metrics+Plugin but not the per job success and failure counters you'd need to build what you suggest. That would make a good addition.

Curious why you need sandbox builds if you've got builds per branch?

So the point here is that the weather icons are slightly misunderstood and underused.

Way back in the way back, a colleague and I were looking to get some extra information onto the Jenkins (then Hudson) jobs screen. I had some chats with KK over IRC and at the time he did not want to open up having multiple columns in the jobs screen. His then view of the world is that the jobs screen should be somewhat opinionated and clean.

So I said, well what about if we add just a second icon beside the status ball and if you hover over it you get a tooltip that displays some detail message. KK said that didn't seem so bad... so off hacking I went.

What I wanted was a kind of health column that would tell you the worst health of your job at a glance.

The idea we had was that some jobs may have low test coverage, some jobs may have a flaky build, some jobs may have lots of TODO comments in the code, etc. So you would define the criterial levels of each metric and score jobs against those levels.

Then we would pick the worst score and display an icon for that score.

So off looking for icons I went... keeping in with the Tango theme that was used by the project at the time...

My initial idea was that you would maybe have a heart that gets into worse and worse shape as the score went from 100% to 0%... but the red colour was too distracting...

So I soon realized that - unlike the status balls - we wanted something that was not quite as high a contrast. You want to see the status balls first... if something is yellow or red, you fix that first... only when everything is blue do you want to start looking at the health (which is why the column is called "H")

What I did find is that the weather icons gave me 5 levels of "health" and were subtle enough not to distract from the red and yellow balls... plus my colleague and I thought it would be really cool to have the code coverage metric be an umbrella and as the code coverage gets worse the umbrella would loose bits of fabric so that 0% coverage would be a tattered frame.

So I had my patch and submitted it to KK and it got merged and the rest is history.

For the initial patch I wanted there to be something for every job already, so the default job health is based on the last 5 builds (because there are only 5 levels of the default icons, and scanning any more would just be pointless)

We also added contributors for the code coverage plugins and the violations plugin (which my colleague was the initial author of)

Then of course you get distracted in other things...

What disappoints me greatly is that in the 700 or so releases of Jenkins that have had the weather icons... nobody has actually gone and implemented the custom icons for job health feature that is embedded directly in the code and was available from the very first day the patch landed...

I don't know if this is because the weather icons are just enough... or if it is because nobody noticed that you can do that...

I know for the code coverage icon, neither Peter nor I are good enough artists to come up with 5 levels of umbrella in various states of disrepair... another idea was a pie chart or a small trend graph... but we always seemed to have more important things to do... and since I joined CloudBees I've been too busy to get back to that area.

So anyway, I guess my point is that the weather icons were designed to be more subtle than the build status and the API was designed to allow plugins to contribute their own health and even their own icons... but whatever about other plugins contributing to health reports... nobody has bothered to contribute the customized icons!

-Stephen (the originator of the weather icons in Jenkins)

I like the weather icons.

In less disciplined environments (most likely the majority of dev environments) they help nudge people by showing that the track record is less stellar than the green icon shows.

Please keep them :)

That was certainly the use case that I had in mind for keeping them around. Need to weigh this up more but I am glad you like them regardless.

If it helps, I can actually provide several data points from companies I've worked for. I've managed 3 (4?) large Jenkins installations and after the initial exploration almost all developers I've worked with understood what the weather icons meant and liked them. Managers definitely liked them :)

Could the current general lack of appreciation for them be related to where they are located in the Jenkins UI?

In Jenkins 1.x and 2.x they are visible on the top level dashboard alongside the green/blue orbs and I often wonder if that's a source of distraction because I (as a user) am looking at both of these indicators now and wondering how to interpret the state based on both of them, when maybe I shouldn't.

Would it help if the top level dashboard(s) contained only one general build status indicator (vs two), and then the trend/health indicators were "down" on the pipeline details page alongside other health/metrics info (static analysis info)?

Yes, please, either remove them or at replace them with something more meaningful. Every time I see one I have to hover over it to figure out whether something's actually wrong, and (confession time...) sometimes I even deliberately trigger a bunch of (non-)builds so it goes sunny again.

If you want to show the state of the last 5 builds, then... show the state of the last 5 builds. e.g. ynyyY (imagine unicode ticks and crosses instead)

Just my tuppence. For the record, Jenkins is amazing in how it has sparked a revolution in the CI world, and I love it, but the weather icons do wind me up somewhat.

Edit: replaced unicode ticks and crosses with y and n because they weren't showing up.

A mini pie-chart would suffice to show recent history. Current status could be in the center with five or six slices around the perimeter showing historical results.

Pie charts are almost always a poor way to show information.

http://www.businessinsider.com/pie-charts-are-the-worst-2013...

For what you're suggesting a horizontal thermometer shape might work, as that would make the historical order more obvious

(Y)nnyyn

That's a great idea - will take it into consideration :)

They are poor for showing relative proportion. In this application they would be fine since it would only be ancillary info that doesn't need to be scrutinized.

It's not supposed to be just recent history. The weather is also supposed to be:

* the code coverage of the most recent build,

* the findbugs / violations count of the most recent build

* any other health metric that plugins decide to contribute to the build.

The icon is supposed to be the icon of whichever report is the worst health and FTR each plugin has always had the option to define their own icons (see my other reply for a more detailed background)

Yeah, I personally have never found the weather icons to be very useful for many of the same reasons already outlined in this long sub-thread. If that's because I didn't "understand" them properly, well then that's a signal of UX failure imo.

I personally think that if users have to think too hard about what an icon (or status indicator) means, then something's not right with it and you need some other visualization for conveying whatever message it is you're trying to be convey.

For me, the weather icons have never passed that test because, at this stage, I've heard multiple people on different occasions say that they find them confusing. That, to me, tells me that they don't work and a different visualization is needed.

Very good news. I love Jenkins but the interface is not very friendly and even with some themes templates like this one https://github.com/jenkins-contrib-themes/jenkins-material-t... it's still hard to navigate and get right informations. Definitively yes for this integration!

Thanks for the kind words :)

I love Jenkins, and it's incredibly important for our teams. The redesign offering much stronger focus on the pipeline is key in helping us (and perhaps many) teams move past the "Continuous build tool" phase and into the "Continuous integration/deployment" tool we would love!

Only possible due to the team working on Jenkins Pipeline and the plugin developers who've started adopting it in their plugins.

Happy to hear you love Jenkins too :)

I have worked with many open and proprietary CI tools, and find GoCD to be the best in this space right now. It supports both Continuous Integration and Continuous Delivery. They also made it open source last year:

https://www.go.cd/

do you work for thoughtworks?. Every single post about Jenkins ends up with bunch of people from thoughtworks blindly shilling for their ci software.

Do you guys mind not doing that please?

Those of us at Pivotal come and rave about Concourse. So I guess it evens out.

GoCD was an important step forward conceptually. It's just an actually awful piece of software to try and use.

This seemed like quite the assumption, so I did some light digging. This person definitely does not work for ThoughtWorks.

I observed this pattern from previous jenkins posts.

But I did some digging after your comment and there it is

http://www.indix.com/blog/life-at-indix/employee-spotlight-k...

  What did you do before Indix?
  I was working at ThoughtWorks as a software engineer.

Well done I guess :) I worked briefly at ThoughtWorks, but definitely don't have any vested interests. ThoughtWorks produces not-so-great products too (like Mingle), but Go CI is definitely a great piece of software. And, I say that as someone who also has used Jenkins a lot.

Also, it's now completely open source. I'm not even trying to advocate an enterprise product.

What's the difference between Continuous Integration and Continuous Delivery?

CI is about the automation of testing code changes before they are merged into the main branch of development. CD is about deploying changes automatically in a live environment.

There are two CDs: - Continuous Delivery - Continuous Deployment

The first one just delivers the packages, but the deployment is triggered by human.

We're running both GitlabCI and Jenkins (different teams) inhouse. Gitlab really upped their Game with the integrated Docker repo (we've adopted Docker heavily) but it is lacking the plugin ecosystem of Jenkins.

Jenkins on the other hand just feels dated. The new ui is very welcome.

Looks like we're going to keep the dual approach for a while until things crystallize further.

Anything you think we could do to shorten the gap between the two?

Integrate into Gitlab, so we do not require a secondary Service. :)

What Jenkins plugins do you need that are not available as features in GitLab?

I wonder how fast cloud bees will upgrade their new exam [0] based on version 1.625.2 of the Jenkins core? The exams where only available since last month and already quite outdated since version 2.0 was introduced [1]. What alternatives to exams exist to asses someone's knowledge and experience in using, managing & maintaining an application?

[0] https://www.cloudbees.com/sites/default/files/cje_study_guid...

[1] https://news.ycombinator.com/item?id=11362058 & https://news.ycombinator.com/item?id=11574487

actually the Pipeline plugin was listed in the study guide, which was probably the biggest change of 2.0 anyways (where it is now by default installed as a Recommended Plugin) :-)

Looks much better!

I've never used Jenkins for my own projects but I've used it before when Minecraft's 'bukkit' framework used to use it and it's a horrible piece of web software to navigate.

It's still being used by the successor of bukkit ;)

https://hub.spigotmc.org/jenkins/view/All/

This is excellent news. Jenkins is often the hardest thing for people to get to grips with in a CI pipeline solely because of the UI/UX, and I, for one, welcome our redesigned build butlers... :)

Looks really great! Much more modern and visually clean.

Thank you!

About time! This is great.

I've yet to find a build system that is better than TeamCity.

It's interesting how little attention it gets. I believe it's mainly because it costs money which is a silly reason. I've worked with many clients who spent hundreds of thousands of dollars on getting software built. Yet only one client ever went fire Team City. No one else even considered it because it costs a minute amount of money. To me the option of selecting a snippet of code in the editor and running it on Ci is worth a lot.

This is a fantastic upgrade to Jenkins, well done.

Sincerely,

A Concourse Fan.

Thanks jacques! Keen to know if there are any gaps between concourse and Jenkins that we could be doing a better job of filling.

Edit: oh right you work for Pivitol ;)

I do, first in Labs and now in Cloud Foundry.

On the Labs side lots of our clients are still committed to Jenkins, so improvements like these are very welcome.

CLASSIC HN (2 Months ago)

https://news.ycombinator.com/item?id=11362058

>Jenkins 2.0 Beta

Almost every top level comment is very negative.

I just think the discussion now vs the discussion then is worth noting. People seem much more positive about jenkins just in the last few weeks.

Recently since it was integrated into Azure those negative comments have started to get downvoted, in favor of positive ones.

https://news.ycombinator.com/item?id=11737374

Very interesting. I figure this is just the more "corporate culture" here on HN.

Reply on news.ycombinator.com