If we fail to fetch an expected manifest (eg, it returns a 404),
then currently the fetch of the build info is marked as a failure
and the ui says that the build does not exist. This is misleading
and we should actually display as much build info as we have even
if we weren't able to fetch the manifest.
This change will cause, in the case of a 404 for the manifest, a
toast to display the error regarding the fetch manifest failure,
but underneath it the rest of the build page will display as normal.
The line being removed was intended to avoid a failure which can happen
if the user visits a log page and the manifest has not been fetched.
However, the user is only likely to visit the log url if the manifest
has been fetched since the manifest is required to supply the index
of log files. So this case does not need to be specially handled.
Change-Id: If87a8de8895c4556306cd7145f4a235b6f786a6a
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
This removes some noise where build output was shown as a failed task
even though failed_when: false was set since the return code did not
indicate a success.
See 'Check if pip is installed' and 'Check if tox is installed':
https://zuul.opendev.org/t/pypa/build/47bbfc21b08744a8bcfd427cbec8f3ac
Change-Id: I775c9145f5c4a4b16ada0dd698874b0928572f01
When opening the builds page there is a short moment when an empty state
pattern is shown before the data is actually fetched. This happens for
the build itself ("Build not found") and for the tab contents like logs,
task summary and console information ("This build does not provide any
..."). The same applies for the buildset page on initial load.
Interestingly, this moment is extremely short in chrome (so you can't
even see it without actually pausing the state transitions with the
redux developer tools), but in firefox it's much longer so you usually
see it when opening the page.
To avoid this from happen, this change does two things.
1. It splits the build, manifest, output, hosts and errorIds into
separate fields of the state. This allows us to fetch as much in
parallel as possible without always waiting for the actual build to
be present. To simplify the usage in the Build page react component,
we use the mapStateToProps() function to combine all those values
into a single build object.
2. Unfortunately, this is not enough as some information like the logs
rely on the manifest entries and the build.log_url to be present. To
still distinguish between a "unknown" value (e.g. the build or
manifest wasn't fetched yet or is currently fetching but we don't
know if it will be found) and a "non-existing" value (e.g. the build
or manifest could not be found after fetching), we use the difference
between undefined and null. In JavaScript tongue, every variable is
undefined that hasn't assigned a value yet (though we could also
assign undefined explicitly). The null value on the other hand is
used to say "I define this variable and explicitly set it to an empty
value".
Thus, we explictly set every entity we didn't found to null in the
reducer functions and check for (undefined || isFetching) instead to
show the spinner animation. This way, the page always starts with the
fetching animation and only switches to showing the result or an
empty state depending on if the entity could be found or not.
Change-Id: I800dfe71128bb00638a51cea0d9be9be623bd923
I think the log-viewer page could do with some PF4-ness.
This incorporates the previous log-viewer page into the builds page.
When selecting a logfile from the listing in the logs tab, the log will
directly show inside the tab rather than on a new page. Breadcrumbs are
used to show the path to the current log file relative to the logs
directory.
Additionally, this change improves the state handling of log files in
redux and allows multiple log files to be stored in the redux state.
This enables fast switching between different logfiles without always
downloading them again.
To remove some boilerplate code, the LogFile component is changed into a
functional component rather than a class component.
The filters are moved from jammed-together links into a button
toggle-group, which is a mutually-exclusive set perfect for this
interface. This component requires the latest release of PF4, which
is why the packages have been updated.
Change-Id: Ibcbc2bd9497f1d8b75acd9e4979a289173d014b2
This also moves the build "slice" of our redux state into an
initialState variable that allow using the same state for testing.
We should move the others slices to the initialState later on as well.
Change-Id: Id1a476a3b82df530a859732f8dab9ef7c11939e5
Currently, when retrieving a buildset from the API we also store the
builds that are contained in the buildset's API result in the redux
store. In case those builds were already present (because e.g. the
build page was visited before) they are overwritten but with less
information. This results in missing links and properties on the build
depending on how the page was accessed.
Since the buildset page is anyways using the builds that are contained
in the buildset directly and the build page fetches the necessary build
by itself in case it's not present already, we could simply remove the
relevant part in the fetchBuildset() action and avoid weird behaviour in
the UI.
Change-Id: I90ffd7f8b3fbd13d623ac94ddfd63b5b58cbffe6
This removes some unused parameters from the various fetchBuild...()
actions, introduces async/await to avoid function chaining and improves
the state-to-props handling on the BuildPage.
The last one is done by using the mapStateToProps() function which
allows us to explicitly map the parts of the redux state in which we are
interested to properties of our React component (BuildPage). This way we
keep the mapping in a single place and don't need to "unpack" the redux
state in various places in our component. In addition we use
mapDispatchToProps to automatically wrap all actions we use in our React
component into a dispatch call.
This change also fixe a bug when trying to call substr() on a missing
log_url. Additionally, a missing log url and a missing manifest file are
no longer treated as failure to avoid showing toast notifications for
those. This mainly applies to noop builds, which by definition don't
provide any log at all.
Change-Id: I056448b8735ac4ed5d271a7f55ca558fe9bf317f
This corrects a problem in the error handler when some request
variables are undefined.
This also handles the case of a buildset with no builds; currently
the REST API omits the builds value in that case, so this updates
usages to handle it.
Change-Id: Ifa09990d08257244f17e77e5c8141bfd8c1cc4d7
If the deployer has indicated that they would prefer the dashboard
to link to index.html files rather than bare directories, do so.
This is in aid of object storage systems where index.html is not
automatically returned for directories.
Change-Id: Iacbc016396f9e6681dd6c945224c5f63af24c5df
Now that the job-output.json file has attributes for 'failed' or
'skipped' tasks, rely on those rather than hueristics for determining
the result of a task.
Change-Id: I2714c5a1776970d5339aafe2ca5e17abf5a3bb0b
This change moves the pure functions out of the TaskOutput component
to separate them from the rendering procedure and help further work toward
PureComponent.
Change-Id: I5ded9ef2c005029eb630837f7fbb78e77de3245e
The code that sets the task result icon didn't look at tasks
with multiple results. To correct this, move that iteration into
didTaskFail and remove it from the task processing.
Change-Id: Ie432fafb7eed26031a952e2832b4c255f1481cc2
This change refactors the Console component to avoid processing
build data in the rendering container.
Change-Id: Ice895b3e4f34a0c3c3369269e3e398de7764e7a3
In the case of a CORS error (which we suspect is similar to the
error caused by privacy badger blocking a request), we get an
Error object with a .message and .request, but no .response.
The .request.responseURL is also empty.
To provide the best feedback we can to the user, let's include
the URL (or the closest approximation possible) to our error
reporting methods, so that if they are called and the responseURL
is empty, we can use the supplied URL as a backup.
Further, if there is no response object, supply the message from
the error and abuse the status field to augment that with some
"helpful" text about network connectivity and ad blockers.
The result is that a user with a blocked CORS request should see:
*Network Error*
(Unable to fetch URL, check your network connectivity, browser plugins,
and ad-blockers) http://example.com/some-url
Change-Id: Ie7b989f9fb1576bfa23ed52c04c0cc308f124baa
There is some magic in errors.js which causes any /.*_FETCH_FAIL/
action to be reported as an error with a popup toast. The attempt
to avoid very long action names by omitting "FETCH" from them has
subverted this. Make sure the fetch actions have FETCH in their
names.
Change-Id: Ie0078f84a668a52db9019ba389bde1c954e8958c
This looks for a zuul_manifest artifact, and if it is present,
it fetches it and shows a tree view of logs. Text logs are
displayed in-app with some basic line anchoring.
Part of the implementation of
https://zuul-ci.org/docs/zuul/developer/specs/logs.html
es6 added to .eslint to allow use of Promise.
Change-Id: Ib04d013b4118005ba66a91d2bec0b0c429d12863
This change updates the build page to fetch the job-output.json file
and display the failed tasks. Logserver needs to enables CORS
header for the zuul-web service.
Change-Id: Ied9d1bb6489f608bc5402a98c8ae3a24b37b91e2
This change updates the build page component to dispatch reducer
action instead of direct axios call. This enables using the generic
error reducers as well as keeping the builds in the store to avoid
repeated query.
Change-Id: I705514e5fa32ec2d81a5b0ca9c5ebb7d8ac6ac2a
James E. Blair