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
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
When updating the redux state one should not directly touch the state
but rather create a copy of the object first, so redux can efficiently
check if anything has changed and the UI components should be updated.
This avoids mutating the state.builds property directly and uses the
spread operators instead to copy the builds dictionary and replace (or
enhance) the data of the build in question.
Since the build reducers are doing rather simple state changes, I also
decided to drop the usage of the immutability-helper library here and
use plain JavaScript instead as I find this much more readable and
straightforward.
Change-Id: I88c68fed99b21bc9a3682e952499fb4fdf74e2d0
This change refactors the Console component to avoid processing
build data in the rendering container.
Change-Id: Ice895b3e4f34a0c3c3369269e3e398de7764e7a3
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
Felix Edel