When using default modules, this feature will add conflicts to
module-build-macros for every RPM in a buildrequired base module
that overlaps with RPMs in the buildrequired modules. This will
prevent them from being available in the buildroot, and thus
ensure that the RPMs from the buildrequired modules (non-base
modules) are used even if they have a lower NVR.
This seems to be better behaviour than simply rejecting the module build
completely. MBS still shows warning in the log that it cannot find
any compatible module, but the build continues with the base module
requested in the submitted modulemd.
A base module can set xmd.mbs.default_modules_url, which contains a
URL to a list of modules in the format of name:stream separated by
new lines. When a module buildrequires this base module, the list
of default modules are added as buildrequires of the module automatically
unless there are conflicting streams or the default module is not
in the MBS database.
When NUM_CONCURRENT_BUILDS is 0, then multi-threading is disabled
when submitting builds to Koji. This is not acceptable, so this
commit makes the number of threads configurable.
There was a race condition, when 2 builds where build in the same time.
There was an issue that after one has finished the other reused the new build
for reuse and not the one it started with.
Ticket-ID: FACTORY-3862
Signed-off-by: Martin Curlej <mcurlej@redhat.com>
* Add docstring
* Call dict.setdefault to simplify the code a little which constructs the map
from package name to built RPMs' NVRs.
Signed-off-by: Chenxiong Qi <cqi@redhat.com>
This commit fixes issue with following situation:
Module `foo` has been built with `buildrequires: platform: [f28]`
and `requires: platform: []`. It can therefore be used as a buildrequirement
on any platform stream. But if you want to build module `app` which
buildrequires `foo` on `platform:f30`, the MBS won't pull-in the `foo`
module build, because MBS currently limits the modules by the platform
they have been built for.
This commit adds new config option to allow including modules built
against any platform stream.
To do this, we need to use the same database session in import_mmd as in
ModuleBuild.get_buildrequired_base_modules, otherwise, the returned
ModuleBuild objects are in a detached state.
This fixes module builds which sets the `buildopts` for something else
than the RPM whitelist.
Before this commit, when `buildopts` was set, the RPM whitelist was
always taken from the buildopts even if it was not defined there.
This resulted in empty `rpm_whitelist` and therefore no pkglist set
in Koji tag.
In this commit, MBS uses whitelist from `buildopts` only if it is
really set by the module maintainer.
Currently, we are using just `conf.arches` and `conf.base_module_arches`
to define the list of arches for which the RPMs in a submitted module are
built. This is not enough, because RCM needs to generate modules based
on the base modules which should use different arches.
This commit changes the MBS to take the list of arches from the buildrequired
module build. It checks the buildrequires for "privileged" module or base
module and if it finds such module, it queries the Koji to find out the list
of arches to set for the module.
The "privileged" module is a module which can override base module arches
or disttag. Previously, these modules have been defined by
`allowed_disttag_marking_module_names` config option. In this commit,
this has been renamed to `allowed_privileged_module_names`.
The list of arches are stored per module build in new table represented
by ModuleArch class and are m:n mapped to ModuleBuild.
In certain use-cases, a module's buildrequires may remain the same
in the modulemd, but a different support stream of the buildrequired
base module should be used. For example, since RHEL 8.0.0 is GA, any
modules that buildrequire platform:el8.0.0 should buildrequire
platform:el8.0.0z instead.
The old way performed a `DISTINCT (module_builds.id)` on the original query passed in
to ModuleBuild._add_virtual_streams_filter, but this caused issues when the original
query was ordered by something other than ID on Postgres databases. This new approach
uses a subquery to filter that module builds with the desired virtual streams, and then
joins this subquery to the original query.
The context column was added in d83e6897ca. The
migration set `nullable=False`, but the model kept the default of `nullable=True`.
This caused `mbs-manager db migrate` to create a migration for setting the context
collumn to `nullable=True`.
This also moves the methods load_mmd and load_mmd_file to
module_build_service.utils.general.
This also removes some MSE unit tests with a mix of positive and
negative streams since this is not supported in libmodulemd v2. The
user will be presented with a syntax error if they try to submit
such a modulemd file.
This will prevent the need to call `SCM.get_latest` in the constructor,
since not all SCM objects need the commit to the branch. It also fixes
the situation where a component's git repo doesn't have a "master" branch.
See https://pagure.io/fm-orchestrator/issue/1224
