* xmd/mbs is always set if it is not present in xmd, so move the code on
the top of function. This change is also helpful for accessing keys
under xmd/mbs.
* By setting xmd/mbs in the beginning, code is simplified to get
disttag_marking and virtual_streams. The result is much straightforwar
for getting a default value for them.
* Move disttag_marking validation code next to the line getting
disttag_marking from xmd/mbs. As a result, the code structure is
easier to read as getting disttag_marking and validate it, getting
virtual_streams and validate.
* Rewrite the part of code for check_buildrequires. Always set
xmd/mbs/buildrequires if it is not present and check_buildrequires is
set to True, as it is required by
ModuleBuild.get_buildrequired_base_modules.
* Using in operator instead of dict.get to check if key koji_tag exists.
Using dict.get would be ambiguous because even if koji_tag exists
under xmd/mbs, but due to its value is set to None occasionally, there
is still a message logged to tell koji_tag is not set.
* Rwrite all lines of code for updating virtual streams. A new method
update_virtual_streams is added to ModuleBuild. This also fixes
FACTORY-4561.
* Tests are added for the rewrite of virtual streams update.
Signed-off-by: Chenxiong Qi <cqi@redhat.com>
The issue is that users don't get feedback from MBS about why a
component was not reused. There was added logic which enables to
store log messages in the database and can be viewed through the
REST api of MBS.
Ticket-ID: #1284
Signed-off-by: Martin Curlej <mcurlej@redhat.com>
When recover_orphaned_artifact is called for module-build-macros
and the module-build-macros is not tagged in the -build Koji tag,
then the tag_artifacts() is called to tag it there.
This is correct, but the issue is that module-build-macros need
to be added to "build" and "srpm-build" Koji tag groups, otherwise
it is not installed in the buildroot by default.
The original motivation for this refactor is to reuse make_module and
drop TestMMDResolver._make_mmd. Some tests require a modulemd created
and some tests also require those modulemd to be stored into database as
a module build. The problem is db_session has to be passed to
make_module even if no need to store into database.
Major changes in this patch:
* Argument db_session is optional.
* Arguments requires_list and build_requires_list are replaced by a
single argument dependencies which is a list of group of requires and
buildrequires
* A new make_module_in_db is created for creating and storing the new
modulemd into database conveniently.
* Tests are updated with the new make_module and make_module_in_db.
Signed-off-by: Chenxiong Qi <cqi@redhat.com>
When resubmitting a module build, if some component is found out that
its attributes have changed, MBS will raise an error to stop the work to
recording components. The problem is original code tells a module build
exists in database already rather than a component build, meanwhile
get_module_name() call on an ComponentRpm object is also incorrect.
Signed-off-by: Chenxiong Qi <cqi@redhat.com>
This patch separates the use of database session in different MBS components
and do not mix them together.
In general, MBS components could be separated as the REST API (implemented
based on Flask) and non-REST API including the backend build workflow
(implemented as a fedmsg consumer on top of fedmsg-hub and running
independently) and library shared by them. As a result, there are two kind of
database session used in MBS, one is created and managed by Flask-SQLAlchemy,
and another one is created from SQLAclhemy Session API directly. The goal of
this patch is to make ensure session object is used properly in the right
place.
All the changes follow these rules:
* REST API related code uses the session object db.session created and
managed by Flask-SQLAlchemy.
* Non-REST API related code uses the session object created with SQLAlchemy
Session API. Function make_db_session does that.
* Shared code does not created a new session object as much as possible.
Instead, it accepts an argument db_session.
The first two rules are applicable to tests as well.
Major changes:
* Switch tests back to run with a file-based SQLite database.
* make_session is renamed to make_db_session and SQLAlchemy connection pool
options are applied for PostgreSQL backend.
* Frontend Flask related code uses db.session
* Shared code by REST API and backend build workflow accepts SQLAlchemy session
object as an argument. For example, resolver class is constructed with a
database session, and some functions accepts an argument for database session.
* Build workflow related code use session object returned from make_db_session
and ensure db.session is not used.
* Only tests for views use db.session, and other tests use db_session fixture
to access database.
* All argument name session, that is for database access, are renamed to
db_session.
* Functions model_tests_init_data, reuse_component_init_data and
reuse_shared_userspace_init_data, which creates fixture data for
tests, are converted into pytest fixtures from original function
called inside setup_method or a test method. The reason of this
conversion is to use fixture ``db_session`` rather than create a
new one. That would also benefit the whole test suite to reduce the
number of SQLAlchemy session objects.
Signed-off-by: Chenxiong Qi <cqi@redhat.com>
This just simplifies the code. It doesn't change the functionality
at all. The tests had to be changed because it assumed that the
xmd.mbs.buildrequires section would be filled out for the input
module which isn't true.
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.
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.
Most of the issues are caused by the use of SQLAlchemy database session. Some
inline comments describe the issues in detail.
Signed-off-by: Chenxiong Qi <cqi@redhat.com>
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>
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.
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.
