Thanks. This is very insightful.
On 05/29/2014 09:51 AM, Kevin Burke wrote:
- Some things don't have API's. For example, *creating a new build
doesn't return the build number*, so you need to GET the job list to get
the current build number and just hope the build you created will be the
next one. See for example
https://github.com/kevinburke/doony/blob/master/src/theme.js#L274.
This is because Jenkins doesn't yet assign a build number while the task
is in the queue.
In recent version of Jenkins, hitting the .../build URL returns 200 with
Location header pointing to the URL of the item in the queue. The caller
can track that queue item and resolve it to the URL of the build when it
actually starts. I should document this better.
Similarly, there's no API for retrieving the console output. There's no
API for retrieving global settings, which would be really nice and allow
people to set items like the text in the title bar, or the theme's
colors, or any number of things. At Twilio we routinely wrote Python
scripts that simulate UI requests to trigger builds etc.
I'm not quite following the part about exposing global settings (Jenkins
does appear to have http://localhost:8080/jenkins/config.xml exposed if
you have sufficient permissions), but if you are thinking about
configurable theme colors and etc, sounds like you'd be writing a
Jenkins plugin, so that can expose the data in any way it sees fit.
Alternatively, you can ask the admin to place something in
$JENKINS_HOME/userContent and that can be seen from clients (see
https://wiki.jenkins-ci.org/display/JENKINS/Administering+Jenkins)
Basically with a UI, my guiding principle is *make the things you do the
most often the most visible*, and the job homepage and the sidebar
aren't great at this currently. I know people use Jenkins in a lot of
different ways, but some user studies or testing could probably reveal
the two or three most frequent use cases, and then the job page /
instance page could be designed around those. One big win I think would
be to move the console output right onto the homepage.
OK, we can do this. Let's do this.
Finally, a few notes about specific points in this thread.
- I'm not sure about bundling websockets/a single page app with a UI
redesign, for a few reasons. For one, it sounds like several large UI
rewrites have failed in the past, which suggests that small, incremental
changes might have a better chance of succeeding than a single bundle
updating a whole lot of things. For example, one week you make the forms
have round corners, add 10px padding between them and and a size 14
font, the next week you make the buttons bigger, the next week you add
an API for global settings, etc. There's a lot that can be done to
improve the UI/usability without necessarily making people upset.
+1. Exactly.
(At the same time I'd still also love to see an experimentation to build
a new subsystem / a part of Jenkins built in more "modern" API-first
manner. I think we'll learn a lot from that.)
Second, I use Travis CI for building most of my Github projects,
but one of my biggest frustrations with it is its occasional ability to
pin a CPU, render a completely blank page, render nonsense, become
unresponsive, etc. Travis CI is a single-page app. The failure modes of
Javascript are legion, especially for people on flaky connections, and
maybe not as well understood as the combination of HTML/CSS/occasional
AJAX requests, for developers. *Jenkins' reliability in delivering a UI
should be considered a core strength.*
- I didn't have too many problems with Jelly, despite never using it
before. However, I did mistakenly edit one template and assume my job
was done, when in fact I needed to edit an additional template to make
the changes I wanted.
<https://github.com/jenkinsci/jenkins/pull/1100/files> The current level
of abstraction makes things a little difficult :) Perhaps a smaller
number of larger files would be easier to edit.
- I also have not had too many problems with content not updating
dynamically; it does so in the places where I expect it to (console
output, triggering builds, though maybe not as quickly as I would like).
One that I've heard and felt myself is the list view, and the orb that
represents the status. A number of people I've worked with in the
Jenkins training course I taught expected the flashing ball to become
solid as soon as the build is done.
(But then I see that you got rid of that bouncy ball completely, so
perhaps that's a non-issue to you)
--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
Try Jenkins Enterprise, our professional version of Jenkins
--
You received this message because you are subscribed to the Google Groups "Jenkins
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
