Switch the authentication method that the koji builder plugin
uses from mTLS to SSO. Since we are using the mock openid
server from the `osbuild-composer-tests` package. Make this
package a dependency of `koji-osbuild-tests`.
Implement support for authentication via OAuth2 using the client
credentials "Client Credentials Grant" flow (4.4 of RFC 6749).
For this a new configuration section is added to the config file,
where the client_id, client_secret and token_url have to be
specified.
The impelmention does currently not support "refresh tokens", but
does support refreshing the token if an `expires_in` is present
in the token itself.
Corresponding unit tests have been added.
[1] https://datatracker.ietf.org/doc/html/rfc6749#section-4.4
Change the integration test so that it adapts to the host, i.e. it
will take the name, version and architecture for the tags and urls
for the repos from the host it is running on. This should make it
more future proof since we now have a central place where this is
configured: the ci configuration, i.e. `.gitlab-ci.yml`.
When the builder is used as an command line binary: have `repo`
be a proper command line argument. It was currently specified
before arch which can be passed multiple times, but so does
repo; hence one of them needs to be optional.
The `run-test.sh` helper is meant to execute the tests as if it
was CI but using a container. If it is detected that we are
already running inside a container assume it is prepare so that
we can exectue the tests directly and do so.
when building the containers the initial `dnf upgrade` will download
content from the latest nightly trees which turns the container into a
Beta system and subsequent `dnf isntall` gets confused!
s3cmd sync actually downloads metadata for all objects in a s3 bucket.
We have built a lot of RPMs, thus this takes 5 minutes on AWS and 25 minutes
on my laptop (!!!).
Let's use recursive put instead. This doesn't delete any files on the remote
side. As we upload RPMs only once, this also shouldn't fail on "the
object already exists". Using this method, we should be able to upload the
RPMs in seconds.
The same patch was applied in osbuild-composer cf73edd2
Let's explain how RPMs for RHEL are built:
We use a subscribed RHEL 8.x machine and mock build these on it. Mock
initializes its own buildroot based on the latest RHEL 8 CDN content, see[1].
This means that the minor version of the buildroot is independent of the minor
version of the host.
However, we currently upload RPMs to a directory whose name consists also of
the minor version of the host. Our hosts are currently running RHEL 8.3 so
the RPMs are uploaded into rhel-8.3 directory despite them being built in the
RHEL 8.4 buildroot (RHEL 8 CDN buildroot specifically). This means that
we cannot guarantee that they are installable on RHEL 8.3 which is weird.
This commit adds a special case for hosts that run on subscribed RHEL and
thus build RPMs in a buildroot constructed from RHEL CDN. These RPMs are
now uploaded into rhel-8-cdn directory. This change more accurately reflects
the way we build our RPMs and removes some confusion.
Also, we need to bump osbuild commit so we have a version that already has
the rhel-8-cdn change in it.
This also bumps all deps so we have rhel-8-cdn repos everywhere.
[1]: https://github.com/rpm-software-management/mock/blob/main/mock-core-configs/etc/mock/templates/rhel-8.tpl#L37
Add support for fetching manifests via the compose/<id>/manifests
API endpoint. A failure to fetch them is not critical, since it is
possible the manifests don't exist, e.g. when depsolving fails.
The manifest is attached per image request.
Previously, we had a webhook relay. It received a notification from Github
and sent it to AWS SQS. Now, the webhook is dead. The new method (already used
in osbuild-composer and image-builder) is to send the notification directly
from a github action to AWS SQS.
