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.
The search input on the Packages step is disabled until needed data is fetched. This was causing a problem on the Additional custom packages step which uses the same component.
A check of the current step was added so the search input gets disabled only for the Packages step.
Previously the base repository links for each distribution were read from `repos.js` file. This gets the needed information
from a call to api endpoint `architectures/{distribution}`. The data is fetched via RTK Query and is then filtered by an
architecture. For now the x86_64 architecture is hardcoded, this will change when multiple architectures get available.
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 adds mock service worker handlers for the
/provisioning/sources and /provisioning/${ID}/account_identity
endpoints. These API mocks are necessary as requests to these endpoints are
now made by the new aws sources feature.
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.
This commit replaces the `getSources` endpoint with an AWS specific
endpoint, `getAWSSources`.
This is necessary because the provisioning/sources endpoint was recently
updated and now has an optional query parameter, ?provider, that allows
requesting sources from a specific provider (aws, azure, etc...).
Unfortunately, the response from /provisioning/sources?provider=aws does
not include the associated aws account id, which has to be requested
from a different endpoint.
The new `getAWSSources` endpoint combines these two requests - first it
requests the list of aws sources, then it requests the associated aws
account id for each source.
Combining these two requests into a single RTK Query endpoint is
advantageous because all relevant information can be retreived with a
single call to the `useGetAWSSourcesQuery` hook.
This commit makes the `msw` server globally available to all test files.
Given that the majority of our test files will ultimately make calls to
APIs using RTK Query (calls are made in both the table and the wizard),
making these globally available in jest.setup.js is reasonable.
This disables the global filter on the top of the page. So later when an option to filter images by name is added,
there won't be multiple filters which could lead to confusion.
We are migrating towards using RTK Query for API calls, and using `msw`
to mock APIs in our tests.
RTK Query's `fetchBaseQuery` requires the use of `fetch` and `Request`.
`fetch()` was added to Node in v18, and the ability to use it in
Jest tests was added to Jest in v28. However, it still cannot be used
with a `jsdom` test environment.
Therefore, it is necessary to add a polyfill. There are several
libraries available for this but many others in this situation have had
success using `whatwg-fetch` and so it was selected somewhat
arbitrarily.
It is also important that `whatwg-fetch` is imported before
`fetchBaseQuery` (otherwise, a nuisance console warning will be issued).
To ensure this happens, it is imported in a Jest setup file.
This commit adds the necessarily handler, resolver, and server to use
MSW for mocking the /provisioning/v1/sources endpoint.
The server can be used in tests like so:
```javascript
// src/setupTests.js
import { server } from './mocks/server.js'
// Establish API mocking before all tests.
beforeAll(() => server.listen())
// Reset any request handlers that we may add during the tests,
// so they don't affect other tests.
afterEach(() => server.resetHandlers())
// Clean up after the tests are finished.
afterAll(() => server.close())
```
As we begin migrating to RTK Query for API calls, we will need a means
of mocking API endpoints for testing that works well with RTKQ. Mock
Service Worker is an API mocking library that uses the Service Worker
API to intercept actual requests and is recommended for use with RTKQ.
https://mswjs.io/docs/
Some additional justification from the creator of RKT Query that
explains why we would not want to simply continue mocking our API
endpoints using Jest:
```
I wouldn't use jest mocking. I would mock the API.
The reason for this being is that your mocks will assume certain return
values from the RTKQ hook - and if your assumptions are wrong, you might
have a nice green running test, but in reality your app will still fail.
An example of this would be using skip and not checking for
isUninitialized - since that case will not come up if you are not using
skip and you might just assume that you will only ever see isLoading,
isSuccess and isError cases in your component. It's a perfectly valid
assumption in many cases, but not always true. Mocking RTKQ would hide
the resulting bug behind green tests.
Instead, I would recommend using something like mock service worker to
just mock your api endpoints and let RTKQ do it's work. That is how we
are testing RTKQ ourselved in our own tests - you are welcome to take a
ook there: RTKQ tests.
```
https://stackoverflow.com/a/70313785
Require const declarations for variables that are never reassigned after
being declared. If a variable is never reassigned, using the const
declaration is better. const declaration tells readers, “this variable
is never reassigned,” reducing cognitive load and improving
maintainability.
Due to merging the openshift and chrome plugin systems there's
additional requirements on the format of the module name.
Camelcase is the default, so the values can just be removed from the
config.
This commit bumps Jest to 29.4.1. This requires adding two additional
development dependencies.
As of Jest 28 `jest-environment-jsdom` is no longer shipped with Jest by
default, and has therefore been added as a dependency.
`uuid` was also added as a dev dependency. Jest 29 introduced some
compatibility issues with `uuid` that were fixed in `uuid@9`:
https://github.com/uuidjs/uuid/issues/451#issuecomment-1206284480
We import and use `uuid` in our tests, but as it was a dependencies
dependency we did not control which version was installed. Version 8
(what was installed) causes Jest tests to fail like so:
```
SyntaxError: Unexpected token 'export'
> 29 | import { v4 as uuidv4 } from 'uuid';
```
This commit adds the /provisioning/v1/sources endpoint via a new
apiSlice.js which uses RTK Query's createApi method.
RTK Query allows us to query the /provisioning/v1/sources endpoint using an
automatically generated React hook, `useGetSourcesQuery`. The usage is
something like this (from within a React component):
`const { data: sources, isLoading, isSuccess, isError, error } =
useGetSourcesQuery()`.
This will make it much easier for us to manage data caching and just as
importantly manage loading and error states properly.
Future PRs will migrate data fetching in the other slices (clones, composes,
repositories) to the apiSlice.
For more info on RTK Query, see:
https://redux.js.org/tutorials/essentials/part-7-rtk-query-basics
Fixes#909. Fixes#918.
This updates the order of the releases on the Image output step to sort from newest to oldest. The RELEASES Object was converted to Map which remembers insertion order.
The color of the `Show options for further development of RHEL` option in the Release dropdown select was also changed to blue.
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
