Message classes and FedmsgMessageParser are moved into dedicated Python module
under scheduler/ directory.
FedmsgMessageParser is decoupled from messaging.py by initializing a parser
object with known fedmsg services. This decouple avoids cycle import between
parser.py and messaging.py.
Signed-off-by: Chenxiong Qi <cqi@redhat.com>
Update the integration test README to explain the design of the test
case and test environment code. This should help future contributors.
Signed-off-by: Hunor Csomortáni <csomh@redhat.com>
Until now, it was assumed that the module-build command returned only
one build, so it was only one build_id. However, it is possible that
the module-build command will build more than one builds and therefore
a list of build_ids is needed. Also is needed to watch and cancel more
than one build.
For this reason run, watch, and cancel methods are methods of the
PackagingUtility class instead of Build class. Run method returns list
of Build objects instead of build_id. And it's also possible to cancel
and to watch on all generated module builds.
Until now, to access the configuration of a scenario, the full path in
test_env had to be specified.
This might be cumbersome and error prone.
Create a scenario fixture, to make it easier to access the same
configuration.
Instead of
test_env["testdata"]["my_scenario"]["my_config"]
one can use the following:
scenario["my_config"]
Signed-off-by: Hunor Csomortáni <csomh@redhat.com>
This makes the tests more explicit, but also prepares the ground to
enable canceling test builds during session teardown in the future.
Signed-off-by: Hunor Csomortáni <csomh@redhat.com>
This is how packagers do. Git URL configuration can also be removed.
Also: redirect command outputs, so that pytest can capture them.
Signed-off-by: Hunor Csomortáni <csomh@redhat.com>
MBS will iterate through all the builds in buildrequires to determine
the expected list of arches on the associated Koji tag. In some cases,
these builds do not have a Koji tag. They should be skipped for this
operation.
Signed-off-by: Luiz Carvalho <lucarval@redhat.com>
Module builds take a long time to run, which can be a pain to wait for
during integration test development.
Instead of requiring developers to locally tweak the test code to be
able to reuse module builds, allow specifying the build ID of the module
build to be reused in test.env.yaml .
Signed-off-by: Hunor Csomortáni <csomh@redhat.com>
Please note that this patch does not change the use of database session
in MBS. So, in the frontend, the database session is still managed by
Flask-SQLAlchemy, that is the db.session. And the backend, running event
handlers, has its own database session created from SQLAclehmy session
API directly.
This patch aims to reduce the number of scoped_session created when call
original function make_db_session. For technical detailed information,
please refer to SQLAlchemy documentation Contextual/Thread-local
Sessions.
As a result, a global scoped_session is accessible from the
code running inside backend, both the event handlers and functions
called from handlers. The library code shared by frontend and backend,
like resolvers, has no change.
Similarly, db.session is only used to recreate database for every test.
Signed-off-by: Chenxiong Qi <cqi@redhat.com>
This will result in the error actually being in the state reason
of the failed module build instead of "An unknown error occurred
while validating the modulemd".
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>
