| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
This migrates the Labels, Nodes and
Projects pages to using the react-table
component from patternfly.
Change-Id: Iaa75e70f4b0c25113369939f97a297571f2ea7a5
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
User sometimes tends to copy the value from the "Change" column as a input
for filtering, which would cause a 500 error in API.
To fix this we do a input validation to indicate that the change must be
a integer for example a PR bumber. So that make it clear any other fomat
like a ref or a string with "," is not supported.
Change-Id: Ia25a60429acc48c5773c808be6a900ba9bdf608e
|
| |\ \ |
|
| | |/
| |
| |
| |
| |
| |
| |
| | |
At the moment API call for fetching SSH public key is not documented
anywhere. It's a bit confusing when a user tries to check through
available calls. This call documented only in ``job-content.rst``.
Change-Id: I69a8d8994b1b4e49ac2c5b07690ebb9ff2a62e38
|
| |/
|
|
|
|
|
|
|
| |
On a non whitelabeled setup, allow a user to jump from one tenant to
another without having to go back to the tenants page.
On a whitelabeled setup, make the tenant item non-clickable (the click
doesn't do anything anyway).
Change-Id: I94d27445c65ed5c3f8d02fae9d47d426528d2332
|
| |
|
|
|
|
|
|
|
|
|
| |
There was a type update to our configErrors state from a list of errors
to a dict containing a list of errors and a ready state flag. This broke
the map() call on configErrors in the dedicated config errors page
because you can't map an object only an Array. We fix this by mapping
the objects errors attribute into the page as the config errors allowing
us to keep mapping over it.
Change-Id: Ib84ca9241fb456f9493a07d1c7e1220f5fa925c8
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The change to automatically filter out skipped builds inadvertently
affected the buildsets tab as well since they share the query builder.
This caused the buildsets tab to automatically append a filter which
is invalid for buildsets and therefore return a 404.
This change adds an argument to the query builder to indicate whether
it should include the automatic filter.
Additionally, the query builder had an error which caused it to
append the query in all cases (which affects the otherwise working
builds tab). This change corrects that as well.
Change-Id: Id03eee51b3551c4b32ae3c6b784b0993c4a3779c
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The default merge mode is 'merge-resolve' because it has been observed
that it more closely matches the behavior of jgit in Gerrit (or, at
least it did the last time we looked into this). The other drivers
are unlikely to use jgit and more likely to use the default git
merge strategy.
This change allows the default to differ based on the driver, and
changes the default for all non-gerrit drivers to 'merge'.
The implementation anticipates that we may want to add more granularity
in the future, so the API accepts a project as an argument, and in
the future, drivers could provide a per-project default (which they
may obtain from the remote code review system). That is not implemented
yet.
This adds some extra data to the /projects endpoint in the REST api.
It is currently not easy (and perhaps not possible) to determine what a
project's merge mode is through the api. This change adds a metadata
field to the output which will show the resulting value computed from
all of the project stanzas. The project stanzas themselves may have
null values for the merge modes now, so the web app now protects against
that.
Change-Id: I9ddb79988ca08aba4662cd82124bd91e49fd053c
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This updates the web UI to support the requirement for authn/z
for read-only access.
If authz is required for read access, we will automatically redirect.
If we return and still aren't authorized, we will display an
"Authorization required" page (rather than continuing and popping up
API error notifications).
The API methods are updated to send an authorization token whenever
one is present.
Change-Id: I31c13c943d05819b4122fcbcf2eaf41515c5b1d9
|
| | |
| |
| |
| |
| |
| |
| |
| | |
We currently only show the login button when in the context of a
tenant. Now that we have an auth context for the "root" level of
a multi-tenant zuul, show the login button there as well.
Change-Id: Ic1d39951a0cf481c6fac4700ba9bb9338478cd7c
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currently we only set the auth redux property within the tenant
scope. But we're going to extend authentication to outside the
tenant scope (to optionally restrict access to the tenant list).
To accommodate that, we will always update the auth property in
redux any time our tenant changes (including when it changes to
undefined), and we will wait until we have finished auth configuration
before rendering any pages in the app.
This is effectively a no-op change from the end-user point of view,
except that we may wait just a bit longer (for the /api/tenant/info
endpoint to return) before showing an initial page for a tenant.
Change-Id: I18e74fa205f75a7b020bf23c8652226e5170d88b
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Verifying the auth token and obtaining user metadata involves some
async HTTP requests in the background. If we remove the auth callback
information from the window location too soon, then the UserManager
will not complete the login process. This currently generally works
because this process tends to complete before the /info and /tenant/info
calls to Zuul. However, future changes to support a read-only
authentication requirement will need to alter this sequence.
This approach is more robust and easier to follow. Essentially the
sequence is:
* Return from IdP to /auth_callback
* If /auth_callback is in our location, short-circuit normal rendering
and render only the AuthCallbackPage
* When background processing is complete, onSignIn will be called and
we will set the user.redirect property in redux.
* AuthCallbackPage has an effect callback on user.redirect which will
cause it to perform the redirect away from auth_callback once
signin is complete.
This process leaves the AuthCallbackPage on the screen a little longer,
so this change updates it to use the newer EmptyPage and Spinner elements
that we have been using elsewhere, so if users see it, it appears more
intentional.
Change-Id: I206c020626c7fd73e58efc29dd50376203679721
|
| | |
| |
| |
| |
| |
| |
| |
| | |
There is no /api/tenant/$tenant/components URL, so hide the
"Components" link in the page header when the web ui is accessing
a whitelabel tenant.
Change-Id: I707bf03489016264ce6a37b4eb005e9680de90a2
|
| |\ \
| |/
|/| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We have had an on-and-off relationship with skipped builds in the
database. Generally we have attempted to exclude them from the db,
but we have occasionally (accidentally?) included them. The status
quo is that builds with a result of SKIPPED (as well as several
other results which don't come from the executor) are not recorded
in the database.
With a greater interest in being able to determine which jobs ran
or did not run for a change after the fact, this job deliberately
adds all builds (whether they touch an executor or not, whether
real or not) to the database. This means than anything that could
potentially show up on the status page or in a code-review report
will be in the database, and can therefore be seen in the web UI.
It is still the case that we are not actually interested in seeing
a page full of SKIPPED builds when we visit the "Builds" tab in
the web ui (which is the principal reason we have not included them
in the database so far). To address this, we set the default query
in the builds tab to exclude skipped builds (it is easy to add other
types of builds to exclude in the future if we wish). If a user
then specifies a query filter to *include* specific results, we drop
the exclusion from the query string. This allows for the expected
behavior of not showing SKIPPED by default, then as specific results
are added to the filter, we show only those, and if the user selects
that they want to see SKIPPED, they will then be included.
On the buildset page, we add a switch similar to the current "show
retried jobs" switch that selects whether skipped builds in a buildset
should be displayed (again, it hides them by default).
Change-Id: I1835965101299bc7a95c952e99f6b0b095def085
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| |\ \ \
| |/ / |
|
