The "Activation keys page" link on the Registration step previously led to prod from both prod and stage envs.
This fixes the problem and ensures that the button in stage links to the activation key management in stage and the prod one to prod.
This commit extends the supported architectures to aarch64. In the image
output step (the first one of the wizard) the user is now faced with a
new select choices to pickup the architecture they want to build.
Now the set of compatible targets to build is dynamically loaded from
the backend and the UX changes what's accessible on the fly depending on
what's the user has been selected.
Refs HMS-1135
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.
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 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.
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 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.
Users may visit the Repositories service to add or modify repositories
while they are on the repositories step in the wizard. This commit adds
a 'Refresh' button that will refetch the repositories and update the
table so that the user does not have to restart the wizard to view their
modifications.
To avoid confusion between custom and payload repositories.
Custom repositories will be embedded in the yum config, payload
repositories are used for installing packages.
This commit replaces all calls to the insights.chrome global with calls
to the useChrome() hook (or the useGetEnvironment() custom hook that
wraps useChrome()).
The use of chrome.isBeta is deprecated, the useChrome hook should be
used instead to obtain an isBeta() function. Using the deprecrated
chrome.isBeta pollutes the browser console with warning messages.
This commit replaces the isBeta() helper function with a new custom
hook, useGetEnvironment().
We still sometimes need to know which environment is running outside of
React components, where we cannot call the useChrome() or
useGetEnvironment() hooks. For instance, in the json used to define a
wizard step. Therefore a new isBeta variable has been added to the
form's initialState for use in these cases.
This removes unnecessary sentences from the description of Packages and Additional Red Hat packages steps. The min and max height of the `DualListSelector` was also updated.
Fixes#1065.
This sets buttons on the Repositories and Additional custom packages steps to `CustomButtons` to ensure buttons in each of the steps have a unique ID.
This commit updates the link on the registration step so users are
directed to the exact place where they can manage keys.
Because managing keys through the customer portal will soon become
deprecated (keys will be managed through the keys service on insights)
the text was also changed to be more general.
This commit makes the new AWS sources feature only available in beta.
Note that the RTKQ hooks related to AWS sources are called in several
places outside of the AWS Target step (a prefetch on the Image Output
step and useQuery hook on the review step) but have not been hidden
behind beta flags - this should not present any problems and will make
exposing this feature in stable much easier when the time comes.
This commit adds the ability to specify AWS targets using the sources
service on insights.
This is the first commit to the codebase that makes use of the new RTK
Query endpoints, so I will provide a bit of additional context here:
The sources are obtained by calling the `useGetAWSSourcesQuery()` hook.
This hook can be called in any component where information about the
sources is needed.
A few tricks are used to make the user experience as responsive as
possible.
The `prefetch()` hook provided by RTK Query is called when the user
clicks on the AWS button on the image output step. This triggers the
initial request for the sources, which will then (hopefully) be ready by the
time the user clicks to the next step (the AWS target environment step)
where they are needed.
Because we anticipate a common user workflow to involve using the Create
image wizard in one browser tab and the sources service in another tab,
sources are also refetched every time the source dropdown is opened.
This means that if a user adds a source while in the middle of using the
wizard, they will be able to see it in the wizard's sources dropdown
without refreshing their browser.
Finally, because of the `Recreate image` feature, the
`useGetAWSSourcesQuery` hook also needs to be called on the review step.
Fixes#911. Fixes#912.
This updates the File system step. The changes are:
- changed the toggle group for selecting the mode of partitioning to radio select and updated information for each radio button as mentioned in #911
- added information to the "automatic" option of the file system configuration as mentioned in #912
- updated information for the "manual" option of the configuration as mentioned in mocks
All instances of '3rd party repositories' (and its variations) have been
changed to 'Custom repositories'. This is in better agreement with the
content sources app on consoledot, which generally is called either
'Custom Repositories' or 'Repositories'. Additionally, it is possible to
add and manage Red Hat repositories via content sources, which makes
'3rd party' confusing.
Adds support for 3rd party repositories using the Red Hat Insights
Repositories app on console.redhat.com.
The packages step has been refactored heavily to reduce the bug surface
area and improve its reusability (it is now used in two Wizard steps).
New features related to the Repositories app are currently only exposed
in stage. Because stage and production are quite divergent (they have
different steps, for instance) there are separate test suites for the
production and stage versions of the Wizard. When these features are
moved into production, the two test suites can be merged into one.
This adds a `TextList` with additional information for a chosen activation key in Registration step of the Wizard.
Component `AdditionalKeyInformation` is wrapped within a new component called `RegistrationKeyInformation` for the purpose of displaying the information on the Registration step. As the component needed to use `FormSpy` element to work properly in this context within the Data Driven Forms.
Without it the validation of the form didn't work as expected, because of a persisting reference to the element it was evaluated against.
Popover for an Activation key was also updated according to SPUR mocks.
