This is the first step to have some tests, that we could run against an
MBS instance, to check that it's functionally correct. Ultimately, these
will replace the test scripts (`contrib/test-*`).
This doesn't really do anything yet, but I would like to make sure that
everyone is on the same page regarding how this will be set up.
Signed-off-by: Hunor Csomortáni <csomh@redhat.com>
After merging #1469, CI runs are failing on the merge step
11:33:39 fatal: proposed/devel-build-modulemd - not something we can merge
This seems to be caused by the change to the fetch line. It seems older versions
of git might have slightly different behavior when asked to fetch a branch name.
With the use of C3IaaS, resource contention in the main OpenShift project will
be dramatically reduced. This allows jobs to run in paralle, increasing throughput
and reducing lag time for feedback on changes.
The C3I-as-a-Service system (https://pagure.io/c3i-library/blob/master/f/c3iaas)
enables creation of new OpenShift projects, which will be deleted after a
configurable period of time, and are suitable for building and testing proposed
changes. The MBS-Koji integration tests now make use of C3IaaS, to reduce resource
contention and avoid false failures due to quota limitations.
Query Koji for the real stream name of each module and keep only those matching
requested `stream`.
This needs to be done, because MBS stores the stream name in the "version" field in Koji,
but the "version" field cannot contain "-" character. Therefore MBS replaces all "-"
with "_". This makes it impossible to reconstruct the original stream name from the
"version" field.
We therefore need to ask for real original stream name here and filter out modules based
on this real stream name.
* A significant performance improvement is to avoid repeating call of
mmd.get_xmd() in a looping.
* Function is refactored to avoid call of mmd_to_str twice for a module
build.
* Test using this fixture already has a setup_method to clean database,
so no need to call clean_database again.
* Calculate build context directly without calculating other contexts
together.
Signed-off-by: Chenxiong Qi <cqi@redhat.com>
If KojiResolver is enabled for buildrequired base module and
MBSResolver is used, then `MBSResolver.get_buildrequired_modulemds`
will use KojiResolver to get the list of buildrequired module builds.
Otherwise it uses the current behavior.
To implement this, the `KojiResolver.get_buildrequired_modules` was
split into two methods:
- `get_buildrequired_koji_builds` returns buildrequired Koji builds.
- `get_buildrequired_modules` calls `get_buildrequired_koji_builds`
and finds the corresponding ModuleBuilds in MBS DB.
In this commit, when component reuse code finds out that the base module uses
KojiResolver, it uses the `KojiResolver.get_buildrequired_modules` method
to find out possible modules to reuse and limits the original query just
by the IDs of these modules.
In order to do that, this commit splits the original
`KojiResolver.get_buildrequired_modulemds` into two methods:
- The `get_buildrequired_modules` returning the ModuleBuilds.
- The `get_buildrequired_modulemds` calling the `get_buildrequired_modules`
and returning modulemd metadata.
This also removes the outdated comments around authorship of each
file. If there is still interest in this information, one can just
look at the git history.
