Ah yes, but at what point does paying someone for work make them an employee?
Given that the users of the app in question were being paid by Google, one could argue they are employed... or at least are contractors.
On the other hand, given the users did not have the rights generally associated with being an employee or a contractor... and they were not even getting minimum wage...
But at that point IANAL and courts would need to decide
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 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)
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)
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)
> 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
Given that the users of the app in question were being paid by Google, one could argue they are employed... or at least are contractors.
On the other hand, given the users did not have the rights generally associated with being an employee or a contractor... and they were not even getting minimum wage...
But at that point IANAL and courts would need to decide