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>
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>
