The code made some half-hearted attemps to handle a MBS verbose query
missing the modulemd data, but it didn't do anything logically
consistent - fix it to consistently ignore such modules.
Code in MBSResolver.resolve_requires() to compute filtered_rpms()
assumed the response from MBS has a "rpms" key with binary RPMS
from the build, but this was never implemented.
If allow_only_compatible_base_modules=True, then it's an error if the
module buildrequires a non-xyz base module stream. Give an error message
that says how to override the base module in the modulemd file.
Overriding the platform stream with, e.g, platform:el8.3.1
is necessary to correctly pick up the right build dependencies for some
configurations. Match the fedpkg/rhpkg module-build way of doing this by adding
--buildrequires and --requires options to build_module_locally.
Fix some oddities in the DBResolver implementation of
get_compatible_base_module_modulemds() and make the MBSResolver version -
which was previously just buggy - match that. (Tests for the MBSResolver
version are added in a subsequent commit.)
* If an empty virtual_streams argument was passed in, *all* streams
were considered compatible. Throw an exception in this case - it
should be considered an error.
* If stream_version_lte=True, but the stream from the base module
wasn't in the form FOOx.y.z, then throw an exception. This was
previously treated like stream_version_lte=False, which is just
a recipe for confusion and mistakes.
test_get_reusable_module_use_latest_build() is rewritten to
comprehensively test all possibilities, including the case that changed
above.
test_add_default_modules_compatible_platforms() is changed to run
under allow_only_compatible_base_modules=False, since it expected
Fedora-style virtual streams (versions not in FOOx.y.z form, all
share the same stream), which doesn't make sense with
allow_only_compatible_base_modules=True.
The default LocalBuildConfiguration builds against Fedora - which has
ALLOW_ONLY_COMPATIBLE_BASE_MODULES = False on the server side. Match that
to avoid warnings that f33 isn't in <stream>x.y.z form.
config.allow_compatible_base_modules=False does different things for
build-requires selection and for module reuse. Clarify this in the config
key documentation.
(This config key is really: True: "do what RHEL expects"
False: "do what Fedora expects")
Two problems occurred with the moksha/twisted handling of SIGINT:
* While KeyboardInterrupt caused the moksha loop to exit, it just
left the test in a confused state, instead of triggering standard
pytest behavior and aborting the entire test run.
* The handler was left-over for remaining tests that prevent Control-C
from working at all.
Fix that by using mock.patch to override moksha's signal handler with
our own signal handler that stores the KeyboardInterrupt in the
current EventTrap, and restores the default signal handler after
the loop ends.
Note that since the KeyboardInterrupt is always handled in the main thread,
we don't get a useful backtrace from the child thread.
Event handlers decorated with @celery_app_task don't raise an exception -
they just log the exception, leaving the Moksha hub running. This meant
that any failures in test_build would result in the test suite hanging
rather than failing usefully.
We solve this by adding a new class EventTrap which acts as a context
manager. Any exceptions that occur in event handlers are set on the
current EventTrap, and the test_build tests re-raise the exception.
SQLAlchemy objects can't be used from multiple threads - so when starting
threads for builds, pass the ComponentBuild id rather than the object.
(Note that despite the comment that the threads were sharing a session,
they weren't - what was passed to the thread was a scoped_session that
acts as a separate thread-local session per-thread.)
BUILD_COMPONENT_DB_SESSION_LOCK - a threading.Lock() object that was used
in a few places - but not nearly enough places to effectively lock usage
of a shared session - is removed.
Because each event handler wrapper would call scheduler.run() at the end before
returning, with a queue of 100 events to process we'd end up
with:
Event handler 1 wrapper
scheduler.run()
Event handler 2 wrapper
scheduler.run()
.....
.... Event handler 100 wrapper
Which would eventually exhaust the Python stack limit. Fix this by making scheduler.run()
no-op if the scheduler is already processing the queue in the current thread.
Using a memory database causes tests/test_build to intermittently
fail, because using the same pysqlite3 connection object from multiple
threads - as was done so that the threads shared the same memory database
- is not, in the end, thread safe. One thread will stomp on the transaction
state of other threads, resulting in errors from starting a new transaction
when another is already in progress, or trying to commit a transaction
that is not in progress.
To avoid a significant speed penalty, the session-scope fixture sets up
a database in the pytest temporary directory, which will typically be on
tmpfs. Time to complete all tests:
memory backend: 38 seconds
file on tmpfs: 40 seconds
file on nvme ssd with btrfs: 137 seconds
MBSSQLAlchemy, which attempted to make the memory backend work, is removed.
Session hooks are installed on the Session class rather than on the
scoped_session instance - this works better when we're changing from
one database to another at test setup time.
We don't need messages at all for local builds, so use a separate "drop"
backend and reserve the "in_memory" backend for tests, where we sometimes
want to inspect the messages. This avoids a warning for each published
message.
The base module conflict generation was skipped for local builds
in 6b2e5be93a because libdnf wasn't ported to libmodulemd yet -
that was done in libdnf-0.45, so only warn and skip for versions of
dnf too old to require libdnf-0.45.
(Don't just unconditionally skip check/warning in case someone is
doing local module builds on RHEL 8.)
Ever since local builds were changed to call handlers directly
instead of going through the scheduler, the current module ID wasn't
set, causing no logs to be written to the module build log file.
No implementations of MBS are using Greenwave, and there are no current plans
to do so. Koji Resolver will be sufficient for any usecase dependent on gating.
