Searching for groups isn't possible sadly, as the search works slightly
differently than content sources. Replace the alert with an alert on how
to use globbing.
Add initial package search. Include the version, release & arch information
in the summary, since some packages might have a release with the specific
architecture and a `noarch` version.
Add a `contentSourcesApi` for the on-prem frontend. We need to add a small
workaround and put these endpoints under the `cockpitApi` reducer.
since RTK query here, doesn't like splitting out apis when they are
fundamentally the same.
To workaround this we can will just chain the endpoints so:
`emptyCockpitApi` -> `contentSourcesApi` -> `cockpitApi`
This allows us to keep the `contentSourcesApi` separate so
we can export some of the endpoints so that the `cockpitApi`
doesn't become a monolith.
This is just a workaround to keep imports to the api definitions the same as before.
The added benefit is that we can then use these files to handle the mixed api types
between the service frontend and on-prem frontend.
Since we will need to add other api endpoints, e.g. `contentSourcesApi` for
the on-prem frontend, this PR restructures the store directory to make future
changes more manageable.
Only invoke the cockpit library when actually contacting the cloudapi.
The cockpit library isn't defined in the service, so any invocation of
the cockpit library when the application loads will make the frontend
crash.
Add a `cockpitBaseQuery` for api calls that need to be made against
the `cloudapi` on the osbuild-composer unix-socket. This function adds
an extra step of parsing the result and transforming it into JSON.
We need to wrap the `cockpit.http.request` call in a
Promise rather than async/await because cockpit rejects
the http request with two arguments (error & data/body)
and we need to handle this appropriately. It is not possible
to do this with a try/catch block
The osbuild release action cleans the repository, removing the tarball
that gets uploaded to the release. This tarball needs to be built before
schutzbot commits the version bump, so move it so it doesn't get
cleaned.
With the custom query functions the cached data from getComposes and
getBlueprintComposes doesn't get invalidated. Luckily RTKQuery provides
a mechanism to invalidate the cache after a mutation.
The structure of the local cache is now:
```
└── blueprint
└── blueprint.json
└── image1
└── image2
└── blueprint2
└── blueprint2.json
└── image1
```
Building an image reads the blueprint, and creates a new image file
under the relevant blueprint folder, which contains the image request.
The image request that's sent off to composer and the request that's
saved differs slightly in the upload structures.
This is not ideal, but we needed to add an empty endpoint for
this, even though we're ignoring it on prem. The frontend for
the service makes the api call regardless, so we can't ignore
this.
