Previously, the Launch/Provisioning wizard was only available in
preview. If an AWS or Azure image was created in preview and shared with
a source, and then viewed in the images table in stable, a popover over
the stable launch link would inform the user that the image had been
created in preview and provide a link to go to preview.
Now that launch/provisioning is going GA and the launch wizard is
available in stable, this feature is no longer necessary.
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.
A ternary operator means that something's going to be assigned to
something, and I think the interpretor might or might not have had
executed that ternary operator before this fix 🤷. Anyway,
rewritten as a if, it's the same as before, except that this time we
know it'll be executed.
Some components were crashing in the test due to a lack of protection
for cases where any data is returned from the API. This solution is
quite temporary and is only ment to allow the unit tests to execute
without throwing errors. A major refactor of the queries is on its way
with RTKQueries and will fix the behavior when data can't be properly
fetched.
The conditional in the image details component needed to have a check
added for vsphere-ova type images.
A mock compose and corresponding status for a vsphere-ova type image
have also been added.
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.
Failed AWS images showed a `Failed to share image to one or more regions.` error even though they weren't shared to other regions.
This was caused by checking for a 'failure' status in an array of `imageStatuses` that included the parent status.
Unleash is being used to determine whether or not to use the Launch
wizard for Azure and GCP images. Unleash is not yet supported in our
ephemeral environments, but we want our ephemeral environments to have
parity with beta. This commit ensures that the Launch wizard opens for
Azure and GCP images in ephemeral.
If an image does not contain a subscription_id property, the link to
view the image in Azure will be malformed. This happens when a user
creates an Azure image in beta/preview using sources, and then clicks
the 'View uploaded image' link in stable.
Now, if an Azure image was created using sources (as evidenced by presence
of a source_id in request's upload options), the Launch button appears
and its popover has a link to Preview.
If an image does not contain a share_with_accounts property, launch
links do not appear in the launch popover. This happens when a user
creates an AWS image in beta/preview, and then clicks Launch in stable.
A message is now displayed that explains the image was created using
Preview features, and the link to Preview has been clarified to be more
explicit.
This disables sharing to new regions in case of failed build of the parent image.
The regions that always end in failure were also disabled in the `ShareImageModal`.
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 error details from the image detail and moves them to popovers activated by clicking on "Image build failed" status.
Popovers were also added for clones which didn't include any error details previously.
This patch adds a constant `MODAL_ANCHOR` so that the value
can be used in multiple modals that require it. Also the
ShareImageModal is now properly anchored to it.
Signed-off-by: Pavel Odvody <pavel@redhat.com>
Insights offers 'quickstarts', which can be used to provide
mini-tutorials in a sidebar.
Unfortunately, these quickstarts change our URL... they add an optional
query parameter related to the quickstart. The process of doing so
destroys our router's `location`, setting it to undefined.
We have been using the location state to store the GUID of the image,
needed when opening the wizard via the `Recreate image` action or when
opening the share modal.
As a workaround, we can simply accept that the quickstarts will change
our URL and destroy our router's location. Instead, we now put the image
id (its UUID) in the route itself. We can access it in the components as
necessary via the useParams hook.
This commit fixes a bug where the Launch link (which opens the
Provisioning wizard) was incorrectly displayed for all image types.
The bug is currently in production beta, so this commit is needed for
the hotfix. Changes made are minimal, only what is necessary to fix the
bug - we still need to discuss the getImageProvider() function (the
original source of the bug) with the Provisioning team.
If a clone is created using a source, and the source is then deleted,
the source will be undefined. Attempting to read the account_id from
undefined causes the app to crash. Optional chaining fixes this.
The Launch service wizard should only be used to launch AWS images that
were created using share_with_sources (and not share_with_accounts) in
their request.
The Launch service only supports a single source at the moment, as does
the Image Builder Frontend. Therefore, we do not pass the entire
share_with_sources array - only the 0th element, which should be the
`only` source for images created using the front-end. We do not expect
full compatibility between images created using the API (which could
theoretically have multiple sources in share_with_sources) and Image
Builder Frontend.
