This updates the web ui to handle multiple changes per item. It
is compatible with the current data output as well as the upcoming
API.
Change-Id: I536967e51b22b60c8ff7baa46b902a36d1ea44dd
This changes the job progress bar to red, and also the job's component
of the queue item progress bar to red in the case where an early failure
in the job is detected. This lets users see what has caused the queue
item to flip to the failure status before the first failure report.
It also adds some explanatory text to the job progress bar mouseover.
Change-Id: Ic9fd1eb000b6a6fce44d2c820dedc02fb0ca9438
This adds a theme selection in the preferences in the
config modal and adds a new dark theme.
Removes the line.png image and instead uses CSS
linear-gradient that is available in all browsers
since around 2018, also fixes the 15 pixels spacing
issue that is there today.
You can select between three different themes.
Auto will use your system preference to choose either the
light or dark theme, changes dynamically based on your
system preference.
Light is the current theme.
Dark is the theme added by this patch series.
The UX this changes is that if somebody has their system
preferences set to dark, for example in Mac OS X that is
in System Settings -> Appearance -> Dark the user will
get the Zuul web UI in dark by default and same for the
opposite.
This uses a poor man's dark mode for swagger-ui
as per the comment in [1].
[1] https://github.com/swagger-api/swagger-ui/issues/5327#issuecomment-742375520
Change-Id: I01cf32f3decdb885307a76eb79d644667bbbf9a3
For heavy users of "dispatch jobs" (where many jobs are declared as
dependencies of a single job which then mutates the child_jobs
return value to indicate which few of those should be run), there
may be large numbers of "SKIPPED" jobs in the status page and in the
final job report, which reduces the usability of both of those.
Yet it is important for users to be able to see skipped jobs since
they may represent an error (they may be inadvertently skipped).
To address this, we remove "SKIPPED" jobs from the status page by
default, but add a button at the bottom of the change box which
can toggle their display.
We remove "SKIPPED" jobs from the report, but add a note at the
bottom which says "Skipped X jobs". Users can follow the buildset
link to see which ones were skipped.
The buildset page will continue to show all the jobs for the buildset.
Change-Id: Ie297168cdf5b39d1d6f219e9b2efc44c01e87f35
The scheduler may now skip pipeline processing if there are no
pending events. And we only write the status JSON to ZK when we
process pipelines. That means that the JSON received by the web
app may be very old. Everything in it should still be correct
except for the calculated values such as elapsed and remaining time.
This means that if a tenant is less active, the times and progress
bars may appear frozen. To mitigate this, use the absolute timestamps
and calculate the relative times on the client.
Change-Id: Ia2bf8bb3b5495e3db13723f81c44186e5ca6ff53
We currently supply no "waiting status" information (which would appear
in the mouseover text on the status page) for jobs that are queued.
This represents jobs for which we have submitted a node request but the
build has not started.
This change adds two new "waiting_status" values: the node request id
for the period between node request submission and executor build
request submission, and the string "executor" for the period between
executor build request submission and build start.
This updates the status page to display waiting_status as mouseover
text for the "queued" status label.
Change-Id: Ic1151944f4a8da8d1ab0a3ae96efb0877f86aebd
Add a "promote" button in the actions menu of a change, if the
currently logged in user is an admin on the tenant and if the pipeline
is dependent.
Clicking the button opens a modal, so that the user can confirm her decision.
Change-Id: I8262888aef9ba1a106e0b321cc4cf2e14465b90c
Apparently PF sets <small> to display:block which adds too much
vertical space to the status page boxes. Switch those back
to display:inline.
Change-Id: Ib096fa1de9f5c7678584009fbee51e09794c0b81
Currently 'waiting' jobs are marked the same color as 'running' in
buildset progress bar that is counterintuitive.
Also refactors function for better readability.
Change-Id: Id580b843f9c9fd06468bcdc31c9a0677a132ccc2
Signed-off-by: Andrii Ostapenko <aostapenko@stackalytics.io>
Previously indentation was not checked at all and in order to avoid
reviewers time with style checks, we can enforce it with eslint.
Current js/jsx changes were made by: yarn lint-fix
Note this this change can easily become outdated so we need to
coordinate and merge it quickly as each rebase would loose previous
votes.
Change-Id: I85883fc8db924ad4ce9acad5acdd42aed7e4d0e4
It is possible for a gap in the progress bar to remain empty due to how
we round the width to no decimals. This should allow us to properly fill
the progress bar closer to 100%.
Change-Id: I2fb11660b00abb741dc6b973e449efe05cb5bc9f
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
The buildset progress bar was not rendered using the same colors as the
job statuses itself. This happened because the job results were
interpreted differently for the job status and the progress bar.
There is now a common jobStrResult() function to have the same result
string in both cases. Missing result cases were added as needed.
Change-Id: I202959766e193efacd00b0dc85bf5160f8412a24
At a lot of place, the duration for an item shows the raw value. It
lacks an indication of the unit (ms, s or minutes??) and is not very
human friendly. `480` is better understood as `8 minutes`.
The `moment-duration-format` package enhance moment duration objects to
ease formatting. It has better options than moment.duration.humanize(),
notably it does not truncate value and trim extra tokens when they are
not needed.
The package does not have any extra dependencies.
https://www.npmjs.com/package/moment-duration-format
Format duration on the pages build, buildset and on the build summary.
The Change panel had custom logic to workaround moment.duration.humanize
over rounding (so that 100 minutes became '1 hour'). The new package
does not have such behavior and offers tuning for all the features we
had:
* `largest: 2`, to only keep the two most significants token. 100
minutes and 30 seconds would thus render as '1 hour 40 minutes',
stripping the extra '30 seconds'.
* `minValue: 1`, based on the least significant token which is minute,
it means any value less than one minute is rendered as:
< 1 minute
* `usePLural: false`, to disable pluralization since that was not
handled previously.
That reverts https://review.opendev.org/#/c/704191/
Make class="time" to not wrap, they would wrap on the Status page since
the box containing is not large enough.
In the Console, show the duration for each tasks, rounding to 1 second
resolution. Would ease finding potential slowdown in a play execution.
The tasks do not have a duration property, use moment to compute it
based on start and end times.
Since hostname length might vary, the duration spans might be
misaligned. Use a flex to have them vertically aligned, credits to
mcoker@github:
https://github.com/patternfly/patternfly-react/issues/1393#issuecomment-515202640
Thanks to Tristan Cacqueray for the React guidances!
Change-Id: I955583713778911a8e50f08dc6d077594da4ae44
With the old code using humaized time it appears to always round down.
This means a job that will run for an hour and 45 minutes is estimated
to complete in an hour. With these sorts of estimates it is my
experience that it is better to over rather than under estimate as
people will get frustrated if it takes twice as long to get their
results as is stated.
To address this we can provide a more specific estimate. We can say "One
hour 45 minutes" instead of "an hour". This gives users a much better
indication of when they can expect results.
Change-Id: I705a636cd2483cdd2b880093747b720f91e6f0e3
With help from TristanC, this should create a tooltip when users hover
over the status bar of a running job, that displays the estimated time
left.
Change-Id: I8d386ea9dce81088eb09293e4d9643ce448434f4
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
When middle clicking on the link to the change a user typically
doesn't want the item to expand/contract. Instead it should not react
on this event.
Change-Id: I663732887d0b7b6e13fe38da555e5a092d49f05f
Story: 2005895
Task: 33754
Some job results like RETRY_LIMIT, NODE_FAILURE and POST_FAILURE are
often indicators for problems regarding infrastructure, network or node
provisioning via OpenStack. Unfortunately, they are not that visible on
the zuul status page and often get lost between those PAUSED, QUEUED
and WAITING jobs.
To still differentiate from FAILED builds, I used the orange color
instead of red.
Change-Id: Icbd22a373e4355d3555759214605ab07918cd39b
As a follow-up on https://review.opendev.org/#/c/660960/,
this will add the keyword 'attempt' to the number of retries to clarify
the meaning of the number in the brackets.
Change-Id: Ib8f2492bc91b418eb27b956ed8867282e72a9474
When working with job dependencies, the zuul web UI does not
differentiate between jobs that are able to run and those that are
waiting for another job to finish before they can actually run. As both
are marked as 'queued', this often leads to confusion and people are
wondering why the queuing takes so long. To better differentiate between
these states, this change introduces a new state 'waiting' in zuul web.
Change-Id: Id0e85dc2db9660925209dc3cee365aa5c1241190
Currently, it's not visible in the Zuul UI if a job runs for the first
time or had already a retry. This change adds the number of tries to the
job name if the job had a least one retry.
Change-Id: I75f400b7eec1e623045b600a7bd93846a6ac3090
We wrap this switch statement in a result !== queued check but then have
a queued case. Remove this redundant case.
Change-Id: I920cf2f31c10b82756957d7512b349ceb1a1ad00
Currently we don't set a contextual class for the progress bar when
state is paused. Set it to blue to indicate the job is still running but
with success. The old behavior was default grey which indicates the job
is queued.
Change-Id: Ie2b7d0c6f4246796c0f9d0385b4589a17418ce48
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
The change I074b3a88a893e04d504e9cf21ced14ba86efc7ec has merged months
ago so we can resolve that todo now.
Change-Id: I14b71bfc2c6f8ff3d0777f65e83ee65662d0bcc9
On the status page the font of in progress jobs is slightly smaller
than the font size of finished or queued jobs. This is caused by the
missing class zuul-job-name when constructing the link.
Change-Id: I8dee14334567227ccca74c45ef393c0e7e6e64c9
Show an animated progress bar in the web UI during the preparation
phase. In this phase the job already has a log URL but no 'elapsedTime'
or 'remainingTime', leading to an empty progress bar.
E.g. with large repos the prep phase can take a while during which there
is no visible feedback to the user.
Change-Id: Ia1e25e662f38f2d469eb65a16dd127dbb0414c3c
Currently time triggered items show up as 'NA' in the status ui. If we
want to dequeue such an item we need the ref which is not existing
anywere in the status, not even in the pure json. So add the ref if
it's there and display the ref instead of 'NA' in the status ui if the
ref is set.
Change-Id: Iedae91d96ab91f4b4131da66ee317072f38e376b
Revert "Fix publish-openstack-javascript-content"
This reverts commit ca199eb9db.
This reverts commit 1082faae95.
This appears to remove the tarball publishing system that we rely on.
Change-Id: Id746fb826dfc01b157c5b772adc1d2991ddcd93a
James E. Blair