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.
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)
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?
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...
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!
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
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 :)
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.
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?
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.
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.
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.
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.
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.
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.
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 :)
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!
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.
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:
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.
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...
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.
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)
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.
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)?
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.
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.
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)
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.
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!
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!
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:
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.
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.
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.
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?
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) :-)
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.
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... :)
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.
