This resolve the stream collision by adding specific RPMs to
module-build-macros SRPM as Conflicts.
For more information about module stream collision, please refer to
docstring in utils/ursine.py
Signed-off-by: Chenxiong Qi <cqi@redhat.com>
ModuleBuild.json now includes xmd/mbs/buildrequires in the output JSON
data. As a result, these APIs will show buildrequires by default.
* /module-builds/
* /module-builds/?verbose=True
* /module-builds/$build_id
Buildrequires is accessible like this:
br_module_names = response_json['buildrequires'].keys()
br_module_dict = response_json['buildrequires'][module name]
Fixes: FACTORY-2201
Signed-off-by: Chenxiong Qi <cqi@redhat.com>
Imagine we have "platform:f29.0.0" and "platform:f29.1.0" base modules.
We also have "DBI" module we want to build agaisnt "platform:f29.1.0".
This "DBI" module depends on "perl" module which is only build against
"platform:f29.0.0".
Currently, DBI build would fail to resolve the dependencies, because
it wouldn't find "perl" module, because it is built against different
platform stream.
This PR changes the MSE code to include buildrequired module builds built
against all the compatible platform streams.
It does so by introducing following changes:
- MSE code uses new get_base_module_mmds() method to find out all the
compatible platform modules. This needed new methods in DBResolver
and MBSResolver.
- For each buildrequired module defined by name:stream, the MSE code then
finds particular NSVC built against each compatible platform module.
Side effect of these code changes is that every module now must buildrequire
some base module.
Future use cases will require the ability to find compatible module builds
to buildrequire based on the base module the module used to build. This
commit adds an association table that will contain module build IDs
and the base module they buildrequire.
Addresses FACTORY-3353
This addresses an issue when a module contains builds that have different
names in their NVR than the component name in MBS. This happens with
SCLs for instance. MBS wouldn't be able to find the component to mark
as tagged in the database since it was searching by the wrong name, so the
build would just stall. This uses the NVR now to find the correct build
in the database.
1. Changed ModuleBuild's context property to db column, it's
non-nullable and default value is '00000000' to keep it consistent
with previous behaviour.
2. Changed ModuleBuild.contexts_from_mmd to return a tuple of
(ref_build_context, build_context, runtime_context, context).
3. Updated tests affected by this change.
