Upgrading to PF5 caused the inputs on the file system customization
inputs to stack on each other.
This commit makes them appear in-line again by using the `<Grid>`
component.
Inspiration taken from this PF5 example:
https://www.patternfly.org/components/forms/form#grid-form
This commit:
1. Removes the header from the Data Driven Forms wizard
2. Adds padding around the in-page wizard so it is visually consistent
with the images table
3. Refactors the images table header into a re-usable component that is
now used in both the images table and the wizard
4. Allows the repositories table to fill the available vertical space in
the wizard
5. Adjusts the package dual list selectors so that they fill the
available horizontal space in the wizard
There was a mixup on our side between what is a profile and what is a
policy. Long story short, a policy a super set of rules including a
profile. For now the wizard is only able to apply profiles and no
policies on images. So let's fix the terminology there.
This commit moves the notification dispatching for creating composes and
clones into a more sensible location – the Image Builder API slice.
It is more sensible because it separates the logic of the React
component (the wizard or share images modal) from the logic of handling
the request life cycle (which is now handled entirely in the slice).
There is a subtle but significant change – a new request will be
dispatched for every request. This is the correct way to do things as it
is possible that some requests succeed, and that others fail. Insights
causes the notifications to stack on top of each other neatly, so there
is no UI problem.
To facilitate this, we also need to use use Promise.allSettled instead
of Promise.all.
There was a bug preventing all the partitions required by an oscap
policy to show up in the fsc step. That bug was because the FSC
customizations were only accepted if they matched exactly the fix set of
base partitions directories.
So now there's a bit of string manipulation to avoid that but it's all
patched up.
fixes https://github.com/RedHatInsights/image-builder-frontend/issues/1385
The images table uses the useGetComposesQuery hook to fetch composes and
implement pagination. When this query is used, args are provided for the
offset and limit and a 'Compose' tag is provided for the query.
When a mutation is triggered (causing a POST request to be sent to the
`/compose` end point), the 'Compose' tag is invalidated which clears all
cached data from useGetComposesQuery hooks, which in turn causes the
table to refetch compose information.
If invalidating the `Compose` tag causes a refetch before the new compose
is available in image-builder, the result does not contain the new
compose and the table is not updated to include it.
This commit eliminates the race condition by waiting for the query to be
fulfilled before invalidating tags (and therefore before refetching the
data).
All of the above applies equally to the `cloneCompose` mutation, and its
race condition has also been eliminated.
This commit is loosely inspired by the RTK Query docs section on
pessimistic updates:
https://redux-toolkit.js.org/rtk-query/usage/manual-cache-updates#pessimistic-updates
Typescript complains about the type of the tags. It does not recognize
the tag types that are defined in the same enhanceEndpoint() function.
For now, we simply ignore the Typescript errors. There is some
discussion here: https://github.com/reduxjs/redux-toolkit/issues/1510
When the user clicks on the "create an image" button, the image wizard
shows up replacing the landing page. This allows to keep the quickstart
guides to the right of the wizard while the user is interacting with it.
When the user has selected a profile to customize their distribution,
the FSC step now shows immediately the manual configuration opened up
with the partitions coming from the profile already filled in.
If the user goes back to the Compliance step and changes anything, the
FSC step is going to be reinitialized.
HMS-2077
Do not show the oscap step outside of beta. Only protecting the step
itself is sufficient since the FSC and the Packages steps wont load any
profile data if no entry point allows to get one.
HMS-2077
wizardrecreatebeta
This commit adds the Compliance step to the wizard. In this step the
user can select a policy from the list of available policies. Their
image is going to be updated with the necessary changes on the later
steps.
IB and The compliance endpoint are both returning the list of policies a
user has access to. The oscap step computes the intersection of the
policies accessible before showing the select list to the user.
HMS-2077
Adding GCP image sharing option according to the discussion on slack(https://redhat-internal.slack.com/archives/C03AZ0264LW/p1692789579814619) and mocks(https://issues.redhat.com/browse/HMS-2352).
In summary, within our GCP sources, we store the project ID. Images cannot be shared directly with a project ID, but they can be shared with a service account or a Google account. Consequently, to launch instances in GCP, users are not required to provide their Google account; instead, the images should be shared with the provisioning service account. This ensures that the provisioning team has access to the necessary images, as sharing them with individual users would not allow that.
After a thorough discussion, we have collectively decided to introduce an option. This option allows users to exclusively utilize the Launch service without the need to share the image with a Google account.
This commit converts the Images Table to Typescript and converts all API
calls to image-builder to use RTK Query hooks.
This should increase the performance of the app significantly.
Previously our calls to the image-builder API were made in series. They
are now made in parallel. We may want to investigate the possibility of
hitting rate limiting now that we will be issuing requests in much more
rapid succession.
In the tests, moving to RTK Query hooks has allowed us to remove
virtually all Jest mocking. However, this means that some of our
previous tests which tested against implementation details were broken.
Most notably, we no longer check the Redux store to verify that clones
have been added correctly and we no longer check that compose requests
were issued successfully. Test coverage will be restored in a follow-up
PR where the dev-dependency @msw/data is added. Adding a persistent data
layer to the tests using @msw/data will allow us to verify that our POST
requests (creating composes and cloning them) are working by testing
that the Images Table has been updated.
This updates the Repositories and Review step as per [mocks](https://www.sketch.com/s/d7aa6d29-fca0-4283-a846-09cc5fd10612/a/MyEbDz7).
Repositories with the unavailable or invalid status have a popover that allows for further inspection. The time of the last introspection and the counter of failed attempts was added to the popover, together with the "Go to Repositories" button.
On Recreate the payload repositories are checked against "freshly" fetched list of repositories. In case any of the previously checked repositories is no longer available in content sources an Alert is rendered on both Repositories and Review steps. The unavailable repository is checked, but the checkbox is disabled and the information is dashed out. Since the information about the repository is stored in the Repository type, the only information available to be rendered is the baseurl.
Create image button is also disabled when recreating an image with unavailable repositories.
Fixes HMS-1492
This changes all occurences of "rhc" and "remote host configuration" from capitalized to lowercase.
In cases where the sentence started with "rhc" this was changed to "remote host configuration" to avoid
starting the sentence with "Rhc".
This moves Beta only features to stable environment:
- Sharing Images through Sources
- Launch button
This tries to avoid any refactoring, just moving components from Beta to stable with minimal changes.
This removes a warning on a no-op being fired when the wizard changes a
state when the request for creation comes back as a success.
Instead don't update the form state if the wizard is going to be closed
anyway.
Incorrect proptype for `selectedAvailablePackages` was causing following error:
```Warning: Failed prop type: Invalid prop `selectedAvailablePackages` of type `object` supplied to `ExactMatch`, expected an array.```
This fixes the problem.
This disables adding of repositories that do not have 'Valid' status.
Status column was also added to the Repositories table to make the reason why the checkbox is disabled visible.
This commit adds eslint support for .ts and .tsx files.
The recommended Typescript rules are applied only to .ts and .tsx files
and not to existing .js or .jsx files. This is accomplished by creating
a separate .eslintrc-typescript.yml file and pointing to it in the
.eslintrc.yml overrides parameter.
A .eslintignore file was added. This file has syntax similiar to
.gitignore and is used to ignore the programatically generated API
slices so that we do not have to deal with a massive diff whenever we
update one of them.
A useEffect was used without conditions to update the value of a state
variable depending on the form state. That's apparent to a way to
initialize the state. Instead, what can be done, is to immediately
initialize the state at the proper value.
These changes were introduced in #1079 to ensure that quickstarts stay visible even after opening a Wizard modal as they are both top-most components.
`ModalProps` which were used for this purpose were introduced in version 3.20.6 of `@data-driven-forms/pf4-component-mapper`. Since then we had to regress the version to 3.20.5 as it was crashing the application on closing of a modal. The issue linked to this can be found here: https://github.com/data-driven-forms/react-forms/issues/1389
As we are now using mapper version that does not allow to use `ModalProps` the functionality of the workaround was lost and it was causing following console.error: `Warning: React does not recognize the `ModalProps` prop on a DOM element.`
This adds validation of an image name based on a pattern, which was chosen as an intersection of the naming constrains of hyperscalers.
The pattern is based on the one for naming GCP images as those naming guidelines are the most restrictive. With added minimal length restriction of AWS.
