| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
This uses react-app-rewired and react-app-required-esbuild to replace
Babel with esbuild to build zuul-web. We do this to speed things up as
Babel is quite slow (6 minutes or so in CI) and esbuild should be much
quicker.
Change-Id: If8f59c0e93e3b8c963ac967e93ffe52b6ba54e06
|
| |\ \
| |/
|/| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In some recent changes I've been looking at the narrow view of the
console page. One thing that remains inconsistent is the magnifying
arrow; it can jump around depending on the page width and in my
subjective opinion it looks a little out of context.
This proposes making a single "pill" for the status and magnifying
icon. The width should be consistent, and the magnifying glass
floating right behind a divider to inidicate it is separate to the
status -- it is also set to not break so it stays together.
Change-Id: I183d4c939a1c74e21198564d1d51e33ecdbc813c
|
| |\ \
| |/ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currently this displays the task OK, Changed and Failure(s) results in
a traffic-light format. I've been looking at the way some other
similar tools present this sort of info, and I think that a few things
stand out
- the orange for the "changed" status is a bit of a red-herring,
because it suggests a warning but really a changed task is as
"good" as an OK task.
- Secondly, the failure case doesn't stand out enough; failures are
going to be the cause of problems, but you get the same
traffic-light for hosts that ran successfully and failed.
- When nothing has failed, we show "0 failures" -- but that is pretty
much implied by things working. It's a bit redundant and puts up a
red box when there isn't a failure.
This proposes moving into a single tasks results label that is either
green for success, or red if there are failures. If there are no
failures, you just see the count of OK/Changed tasks -- if there are,
you'll also see the failed count.
Change-Id: Iebadc4ddb77209f69242ebc5ac46f2ae6d67789f
|
| |\ \
| |/ |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
To keep consistency with the console page
(I6df896497f3a20d639fc67f256e1d2566aa2903c), put the failed tasks in a
light red box to highlight the failure case.
Change-Id: I48e1b616663919787fb52d53ee27882efea825f9
|
| |\ \
| |/ |
|
| | |
| |
| |
| |
| |
| |
| | |
To give more visual weight to a failed task, give it the lightest red
background.
Change-Id: I6df896497f3a20d639fc67f256e1d2566aa2903c
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Clarify the comment from I8a7e8172f784fc69aa0abb2e6787c63c33d3f802 to
make it clearer that we have only seen this behaviour with package: on
yum/dnf/Redhat-ish platforms.
Change-Id: Idc14c5799f0c8e66440f23b175780a00c82bd589
|
| |\ \ \ |
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This updates the OpenAPI docs to include the semaphores endpoint,
and adds a Semaphores tab to the web UI to show information about
semaphores within a tenant.
Change-Id: If78b27131ac76aff93c47a986fce6eae3e068668
|
| |\ \ \
| | |/
| |/| |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I've noticed that when making the console page very narrow (mobile)
the entries are difficult to differentiate in their compressed form.
This proposes adding alternating colors on the play entries to
differentiate them. Since the grey is used between elements, the
highlight is modified to the the lightest blue in the PF family.
Putting a small border-radius on this makes it look a bit more
differentiated.
Change-Id: I7afcb64a5e41348f14bd297c8c8bde27312dff97
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
If the Zuul web UI is placed behind an authorizing proxy system,
such as Apache mod_auth_mellon for SAML, then when the service
provider token times out, users will not receive any indication
that has occurred. If they are watching the status page, it will
just silently fail to update. Switching to another page may bring
it to their attention, unless we already have cached data, in which
case there still may be no indication.
In these cases, the authorizy proxy sends a redirect (HTTP 303)
instead of the normal response, but since our requests are async
background requests from JS, they are subject to CORS rules and
because they arrive without an Access-Control-Allow-Origin header,
the response is unavailable to us. (Even if they do arrive with
that header (say by the use of apache mod_headers with "always set"),
the ultimate target of the redirect also needs to have that header,
which is very unlikely in the case of an ID provider.)
Even though we have no information about the response due to the
CORS restrictions, we can detect this situation, at least with
mod_auth_mellon, and possibly others, by adding the X-Requested-With
header. This can be used to indicate that the request is from JS
instead of the user, and in this case, mod_auth_mellon returns a
403 instead of a 303. We do have access to the 403 response (unlike
the 303) so we can detect this case.
In other words after receiving an undefined response (which could be
DNS, network, or CORS error), we can narrow that down by repeating
the request with the X-Requested-With header, and if we then get
a 403, we can be fairly certain the first error was CORS and that we
need to re-authenticate. We still don't have access to the redirect
target that the auth proxy wants us to use, so the best we can do
is to just reload the page and let the auth proxy perform a redirect
based on the normal user request that this appears as.
Why not always include X-Requested-With? That's because without that
header, the browser considers most of our GET requests to be "simple"
which means that they do not require pre-flight checks (where the
browser performs an OPTIONS request before executing the actual GET).
Adding that header to every GET would double the number of HTTP
requests in normal operation (even for sites without auth proxies),
so it is worth our while to keep our simple GET requests simple.
Change-Id: I7c82110d033550c451d21306de94f223a5fcceb2
|
| |\ \ \ \
| |/ / /
|/| / /
| |/ / |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
To recap, a PF DataList doesn't have a built-in way to hide the
"expandable content" toggle, so on the console page the items -- which
have a mixture of expandable content and not -- don't line up.
In I33fdafb4e5b98e546c8615a3d65f52c944521cf7 I tried to fix this by
using a visibility:hidden toggle, based on ideas from the comments in
the inline github issue.
What I didn't realise is this doesn't work quite correctly on very
narrow (mobile) views. The problem is that the class hierarchy needs
to look like
<row>
<control>
<toggle button />
</control>
<content>
<cell />
<cell />
...
</content>
</row>
The reason for this is that the <content> is a grid placed *next* to
the <control>. So when it squishes up, it should look like
|-- |
| > | name
| | <magnifying> <status>
| | <time>
|---|
With my first attempt, the hidden toggle ">" had all the right
classes, but was part of the content. This looks fine when all the
content is in a horizontal line; but when it gets to a very small page
width we end up with a hidden toggle button in a single column *above*
the name, pushing everything down
| > hidden button <
| name
| <magnifying> <status>
| <time>
This leads to a large gap between items and misalignment on small
width devices.
Upon further reflection, it has struck me that we don't *have* to use
the React compontents, and what we need to do here is build our own
datalist item from the PF classes directly, as if we were writing with
PF in HTML. We do this here, adding the hidden to the expandable
button.
This works on all my testing, and the generated output via the
browsers console inspector looks the same as using the React
components. Obviously if PF merge a change where we can do this via a
prop to the compontent it is much more idiomatic to React code, but
this should work fine too.
Change-Id: I2048554f46b6ef3ec5410967e00400a593c572d7
|
| |\ \ \
| |/ /
|/| | |
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If a job returns nested metadata (ie, a value that is a dict or
list), the build page will crash when attempting to display this
because it expects metadata values to only be scalars. The docs
and code both say that values can be "anything". Update the
build page so that if the metadata value is an object (ie, not a
primitive scalar), we use a JSON view to display it.
Also, if the value is not an object, use toString so that we
will display boolean values.
Change-Id: I609f70ec60399c69b5f8715b97c43f513c7360a1
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Inspried by comments in [1]; put a disabled and non-visible button
styled in the same way as the expandable content button here as
padding for items that don't expand.
[1] https://github.com/patternfly/patternfly-react/issues/7950#issuecomment-1239895122
Change-Id: I33fdafb4e5b98e546c8615a3d65f52c944521cf7
|
| |\ \ \
| |/ / |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This makes the magnifying glass also clickable in the console view.
Change-Id: I0081bd19a336390572050d4bf3d8b456a71ca7d2
|
| |\ \ \
| |/ / |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
A small refactor on the item generation to only create either an
expandable version or not; not both.
Change-Id: Ifabbd6775b516ca5829a691f5a19e325c30a786c
|
| |\ \ \
| |/ / |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The current logo has a lot of whitespace around it and is offset with
the viewbox. I've imported this into inkscape, selected just the logo
and re-exported it with no whitespace, then ran it through the
minimizer at [1].
I've set the height to 1.5em -- the icons in the same bar have a
height of 1em; to my eye this look good just a bit bigger than that.
[1] https://jakearchibald.github.io/svgomg/
Change-Id: Idf4e676d33a4626c0b80e06986d8b24b41924065
|
| |\ \ \
| |/ / |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Change Ib1b6be1b554b30ce7a7d2aacae476cefbed63782 modified the CSS so
that this inherits via <Page>; this explicit class isn't needed any
more.
Change-Id: I36dd2869c4b95eea57d3cd8024311606429bf025
|
| |\ \ \
| |/ / |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I am currently getting the below error in my console about the type
passed to AutoholdModal. Convert the change to a string.
Warning: Failed prop type: Invalid prop `change` of type `number` \
supplied to `AutoholdModal`, expected `string`.
in AutoholdModal (created by ConnectFunction)
in ConnectFunction (at Build.jsx:273)
in Build (created by ConnectFunction)
in ConnectFunction (at Build.jsx:254)
in section (created by PageSection)
< .. and so on ..>
Change-Id: I9c9a5edfa18f0344ac4a50c62c798a5d4e404c18
|
| |\ \ \
| |/ / |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The task modal title is very sparse; since this can be deep-linked it
should provide more context.
This adds the task description as the main title, then adds the
status, node and deeplink icon as the modal-description. This should
give more context to what is going on, and everything is styled the
same as on the console page so it's visually consistent.
Change-Id: I804d2eba9d67ed3a8781aa15ab6a14a2434329bb
|
| |\ \ \
| |/ /
|/| | |
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This feature instructs Zuul to attempt a second or more node request
with a different node configuration (ie, possibly different labels)
if the first one fails.
It is intended to address the case where a cloud provider is unable
to supply specialized high-performance nodes, and the user would like
the job to proceed anyway on lower-performance nodes.
Change-Id: Idede4244eaa3b21a34c20099214fda6ecdc992df
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
After converting the console to PF4 with
Ie480deb046502879542e41844e919a362203e25d, flipping back through the
tabs I notied some inconsistency with the "Task Summary" tab.
Firstly this puts a <br> so it is vertically aligned the same as the
other tabs. We remove the card around it because nothing else uses
this; now it is a DataList that is the same as the console page. CSS
is added to remove the top line which is also inconsistent with the
other tabs.
We convert the node to a chip with a node icon as used elsewhere.
Future work would probably be to put the failed tasks as expandable
content in each node's summary line.
Change-Id: Ic134cf560cc78540f6af71964ac366f89ca594d9
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is a selection of rules to override the default datalist layout;
it removes the lines and compresses entries. This is the result of
inspection and trial-and-error; i.e. there may be better ways to do
all of this.
The box-shadow on hover mouseover doesn't really work that well with
the compressed entries, as they are too close together to get a good
offset for it. This replaces it with a light background; the hover
should also highlight on the left.
Change-Id: Ie3d79b11be517136a62db61c57a112885b0e10eb
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The console page is currently based on the ListView from PF3. The
most direct conversion to PF4 is a DataList, which is similar but
different.
This is intended to be a like-for-like replacement of the console page
using the DataList model.
The things I have explicitly thought about:
* The trusted flag on the playbook remains with tooltip
* The task line output is the same order, with
task <+>- (STATUS) [hosts] <time>
The magnifying glass and status share a cell to keep them close
* You can click on either the magnifying glass or the status to bring
up the modal with the full task status. Both have a tooltip.
* The status and hosts are modified to use PF4 label and chip models
for a standard look.
* Plays start rolled up, but tasks start in the expanded state as
before.
* If there is a failed task, the playbook and play are unrolled to
show it automatically as before.
* "run" playbooks are expanded by default
* Tasks highlight on hover, but now using a light boxshadow rather
than background color which is more consistent with other parts of
the ui (like the build table, for example).
* No colours in the background of the playbook rows; the DataList now
has a blue line that runs down the side showing you the groupings
when a playbook row is opened. I think this is more consistent
with "less is more" type approach.
* deep-link permalinks on the modal display of the task results open
up the same task display when pasted into a new window.
While I think there is plenty of room for improvement in the way this
information is displayed, I've deliberately tried to keep everything
the same in this changeset to a) ease review and b) so we have a
PF4-based grounding to work from. There wasn't really a way to do
this more incrementally; although almost everything moves around there
is no tricky code to call out -- some fiddling of things that needed
to state properties and some toggle javascript-code bits are the main
additions.
Change-Id: Ie480deb046502879542e41844e919a362203e25d
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is the result of "npm udpate @patternfly/react-core" which brings
in 4.235.7, which is 2022.11 release (2022-08-31) [1]
The one thing I want from this is that it adds the ability to size
Chip elements, which is helpful when using them as node icons with
nodes that have long names.
[1] https://www.patternfly.org/v4/developer-resources/release-notes/#2022.11-release-notes-2022-08-31
Change-Id: I83061e9b38916d88711a06e3c38b83d7649967fd
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This was suggested and written by Joachim Schuler in [1]. It moves
the top navbar as a "tertiary" option to the page header. This bar is
always visible and doesn't roll-up into the "top" area. This means we
can drop the more complex grid layout that is trying to keep this bar
always visible for some much more simple styling.
As this moves the navbar location the link matching is updated to find
new elements.
[1] https://github.com/patternfly/patternfly-react/issues/7960#issuecomment-1244017295
Change-Id: I4a61a1e246ca4fe0d96f630a06be7f0264782723
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
This was suggsted and written by Joachim Schuler in [1]. It is
probably a bug that due to asynchronous loading of CSS rules our
logo-height rule here sometimes comes and goes. However, putting this
in a zuul-page class both seems to fix this (I always see the logo
now) and is just generally a nicer way to organise things.
[1] https://github.com/patternfly/patternfly-react/issues/7960#issuecomment-1244017295
Change-Id: Ib1b6be1b554b30ce7a7d2aacae476cefbed63782
|
| |
|
|
|
|
|
|
|
|
|
| |
As noted inline, the package: task seems unique in sending back an
array of strings. This completely messes up the output currently,
splitting up every letter of the result into a separate item.
This quick hack just reformats the list of strings into something that
comes out correctly.
Change-Id: I8a7e8172f784fc69aa0abb2e6787c63c33d3f802
|
| |
|
|
| |
Change-Id: I12e8a056a2e5cd1bb18c1f24ecd7db55405f0a8c
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This corrects the tab titles on the project page which currently
typically just say "master", "master", "master", ... because they
all display the default branch of the project stanza.
Instead, use the branch of the source context for the project stanza,
or, if the project stanza is not from the current project, then
use the name of its project.
This causes them to appear like:
"openstack/project-config", "master", "stable/diablo", ...
Also, update the entire Project page component hierarchy to use
hooks instead of classes.
Update the styling on the H2 element so that we can have the
refresh icon share the same vertical space (so that we don't have
large amounts of wasted vertical space at the top of each page.
Change-Id: I863e0eb4a7f20ee6363e596e61cc49b2cbc22953
|
| |\ \
| |/ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When scrolling the project page with a job graph rendered, users
using scroll wheels (or similar input devices) may be surprised
that once their pointer moves over the job graph, it begin zooming
instead of the page scrolling. Disable zooming the job graph
with the mouse wheel so that the behavior remains consistent.
Zooming is still possible with click/shift-click.
Change-Id: Ic3884f1317cb7799e4e387aa51c81c080e028d10
|
