Move the docker backend to the `getting-started` repo in `osbuild` since
it seems like a more appropriate place for the backend stack. Add a note
to the README to point users to the new repository.
Update multiple aspects of our docker development stack. The frontend now
has a devel specific webpack that allows development against a local server/api.
The docker-composer.yaml also includes both versioning and networking updates.
Overall, the major change is to migrate our proxy access into the crc webpack proxy.
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.
The compliance step is now tested with two new tests:
- One to test that upon creation, if a user selects a profile, then the
customizations are applied to the file system and package steps
- One to test that upon recreation, the file system and packages
customizations are still present.
HMS-2077
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
This reverts commit 36f9e70565.
The Compliance v1 API is not stable and not intended for consumption by
other teams. We will implement the OpenSCAP MVP without the Compliance
API for now with a hard coded list of polices in image-builder, and when
their v2 API is ready in the near future begin using it to retrieve
policies.
This commit adds the Compliance service's API, which we can query for a
list of SCAP security policies.
In a follow-up PR, we will allow the user to optionally select a policy
when creating an image in the wizard.
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.
The `<LaunchWizard>` architecture prop was specified incorrectly,
which caused the Instance dropdown in the Launch wizard to fail to load
instance types.
This commit is a hotfix that restores functionality to the Launch
wizard.
The `appendTo` variable can't be recomputed on every render. Wrap it in
a useState() hook to work properly.
Additionally, the `hasAccess` property was missing from the
<ProvisioningWizard> component.
To ensure full backwards compatibility, the component has also been
wrapped in a <Suspense> as it was previously.
The edge images table is going to be integrated in the frontend code
base in the coming weeks. To help smooth that development process there
is need for a feature flag that would keep the current behavior running
on stage and prod while the new image table is being developed.
For now dummy code is returned for when the flag is on, and legacy
behavior keeps on going when the flag is off.
The stage flag can be seen there:
- https://insights-stage.unleash.devshift.net/projects/default/features/image-builder.edge.local-image-table
The prod flag can be seen there:
- https://insights.unleash.devshift.net/projects/default/features/image-builder.edge.local-image-table
The commit brings in some documentation in the Readme. Any member of
the team should be able to follow these steps to add in new feature
flags and use them in the code base.
The commit also brings in two new testing files for the future
components to come. For now these tests only check that the mocking
value for the unleash flag is properly set.
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.
Travis will check that the API suffers from no changes while running
`npm run api` on the PR. If there are changes, an error message will
send the contributor to check the README page about open api generated
code.
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.
The "Step Image output - clicking Next loads Upload to AWS" and "Step Upload to Azure - clicking Next loads Registration" were sometimes returning the "Warning: An update to <element> inside a test was not wrapped in act(...)" error.
This seems to have been caused by an early exit in the `setUp()` function in the first `describe` block.
Safeguards were put in place to fix this behaviour.
As this error didn't occur every time, testing the updates was not easy. This current fix passed the threshold of ten successful runs of `npm run test`.
After bumping to React 18 linter was outputting following error: "ReactDOM.render is deprecated since React 18.0.0, use createRoot instead, see https://reactjs.org/link/switch-to-createroot"
This fixes the problem.
Test `component renders error state correctly` was outputting errors for both AWS and Azure tests.
This was caused by calling `server.use()` after the wizard was already rendered.
Fixed by moving the one time server mock response to the very beginning of the unit test. Also added `server.resetHandlers()` to be run after each of the unit tests.
Thanks to this fix, azure tests could be merged again. Which means no more splitting into `CreateImageWizard.azure.test.js` and `CreateImageWizard.azure.2.test.js`
This updates following test suites after bumping react and testing-library:
- CreateImageWizard.azure.test.js
- CreateImageWizard.azure.2.test.js
- CreateImageWizard.content.test.js
- CreateImageWizard.test.js
