This updates `<ChippingInput>` component to resolve two bugs:
- validation wasn't triggered when using the plus button on Timezone and Locale steps
- error text wasn't reset when the value was changed or cleared
add condition that check if there is value in Hostname, Locale, Timezone steps
and if there is no value, we dont see the extendable part in review step
FIX ISSUE: (#2718)
after changes when there is no value in Timezone step, we should update
test if we want to see the extendable section
We'll be switching NewAlert with blueprints for information about newly available customizations. The component itself is a nice scaffolding for the upcoming announcement, would prefer to keep it for now.
Use the filename/id of the blueprints as the links to
the first and last element for the blueprint list metadata.
These links are a little meaningless since they should be
urls.
Since the implementation of the cockpitApi and imageBuilderApi are different,
we should make sure to export the correct one depending on the environment
we are in.
The filtering was defaulting to version '1', making images of other versions not appear when selecting a blueprint.
How to reproduce:
1. create a blueprint
2. build an image
3. edit the blueprint to get it to version 2
4. build another image
Current behaviour:
- only image with version 1 is visible
After fix:
- both image for version 1 and image for version 2 of the blueprint should be visible when the blueprint is selected
This resolves `Warning: validateDOMNesting(...): <form> cannot appear as a descendant of <form>.` warning in test output. There were two `<Form>` components nested in each other.
It was necessary to do a bit of plumbing to get typescript, webpack &
vitest all happy. To do this we had had to create a separate tsconfig
for the on-prem version and the service frontend.
We override the module resolution for both config files. For on-prem we
check modules in `pkg/lib` and for the service we resolve the modules to
stub functions of the `cockpit` & `cockpit/fsinfo` modules. This was so
typescript and webpack would not complain.
For on-prem we had to intruct webpack to resolve modules from both
`node_modules` and `pkg/lib`. While for the service we set the
resulotion for the two modules to false, which means they won't get
bundled with the service.
Lastly, we needed to set some aliases in the vitest config so that
vitest could resolve the `cockpit` & `cockpit/fsinfo` modules.
Using the cjs `require` keyword to import cockpit would have worked to
make typescript and webpack compile since these imports are not
statically analysed like the `import` keyword is. However, this approach
broke the tests as `require` imports are not supported in vitest.
