When a gcp image is successfully uploaded the user needs to know the
project id, image name, and account the image is shared with. These are
now displayed in a popover accessible from the status section of the
images table.
Remove excessive status elements since there only needs to be one status
statement for each image in the list. Also, replace the pending spinner
with a pending icon.
Remove unnecessary styling on the rows in the images list. Reorder the
columns to put the target and status next to each other. Use upload_type
instead of upload_status. Stop storing columns in state since they are a
constant.
The list of composes is now paginated. The default is 10 composes per
page. This quantity can be changed. When the page or the quantity per
page is changed then the next set of composes will be fetched.
The composeGetAll action is refactored to composesGet. It now uses
passes limit and offset as params so that pagination can be used. Also,
the COMPOSE_ADDED reducer case only adds new compose ids to allIds if
the id is new/unique.
The ImagesTable will now trigger a thunk to fetch all of users composes
on load. The response of the /composes api call does not include status
so we currently only fetch the first 10 composes and fetch the status
for each of them.
Updating a composes status is no longer done from the ImagesTable
component. Instead the composeGetStatus thunk is used to make the api
call and dispatch the COMPOSE_UPDATED_STATUS action. The polling still
occurs from the component.
The compose object should have the initial compose request stored in a
field called request. The id and image_status are independent of the
request so should not be set within it.
The patternfly Wizard component's description is wrapped in a p tag. The
patternfly Text component also uses a p tag. A p tag should not be
nested inside another p tag.
When a compose is started the api call is no longer handled by the
CreateImageWizard onSave function. Instead, the CreateImageWizard
calls the composeStart thunk. This function calls the api and handles
the response. If successful, the compose is added to the store.
Otherwise, an error is added to the store.
The store's compose object now has a list of the compose ids and an
object containing key/value pairs mapping a compose id to the compose
for all composes. This "normalized" state will allow more efficiency
when selecting individual composes or iterating through all composes.
The compose objects in the store now match the composeRequest object
instead of having a shape unique to the UI. This can be changed in the
future if image-builder's api returns compose objects of a different
format.
Tests are updated for new compose format and action/reducer types.
Redux thunks allow actions to pass functions. This will be helpful when
our api calls are moved into redux actions instead of being handled within
react components.
Our compose actions will follow the naming convention of *name*_*event*.
Therefore, when we receive an updated compose from the api, the action
should be called COMPOSE_UPDATED.
The redux reducers and actions are moved to subdirectories within the
store directory. The goal of this is to improve the understandability of
the directory structure and to prepare for future scaling of the actions
and reducers.
osbuild-composer and as a result also Image Builder are returning an
invalid `image_status.status` value "running" for composes which are in
progress.
Extend the front-end to handle all valid `image_status.status` values,
specifically also "building", "uploading" and "registering". Also keep
support for the invalid value "running" for some time to ensure backward
compatibility with older osbuild-composer versions.
Modify test cases in `ImagesTable.test.js` to verify all possible
`image_status.status` values. Also modify the `image_status` values used
for testing to what is actually returned by osbuild-composer Cloud API
and as a result also by Image Builder's API.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
