Porting the latests osbuild version in `osbuild/images` revealed a
regression in error messages returned by the tool in case a non-existent
package is requested in the depsolve request.
Test that requesting a non-existent package results in `MarkingErrors`,
which was the original behavior of the DNF4-based
`osbuild-depsolve-dnf`.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Remove one test case, which does not really add value or extend the test
coverage, since the same thing is already tested by previous test case.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Until now, the unit test tested only very simple case with a single
transaction, which happens only for vanilla images. Any user
customization would result in multiple transactions in the depsolve
request. This case is not yet tested at all.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Modify the function that executes the depsolve command, so that does not
produce exception in case the command fails. Instead, return the message
returned by `osbuild-depsolve-dnf` and the exit code. This will allow to
test also other scenarios (such as depsolve errors) in the test case.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
This commit includes the used sovler in the dnfjson reply. This
is mostly information (e.g. in service logs) but also useful in
tests to ensure that the expected solver was really run.
Note that this needs https://github.com/osbuild/images/pull/723
first.
When the filelists are enabled in the optional metadata, the local cache
for the depsolve will include a filelist file for each repository.
Count the files matching *filelists* using glob() and compare them with
the number of repositories when the option is enabled.
When the option is not enabled, there should be no filelists.
Also fix the test, it wasn't updated to use sslverify instead of
ignoressl. This now correctly passes on -dnf and fails on -dnf5 which
will be fixed in the next commit.
We run tests using tox to set up environments for different python
versions to test against. The problem is that when a test shells out to
a python script, like osbuild-depsolve-dnf5, it's not run inside the
environment but in the system environment. The `has_dnf5()` check
returns False because it fails to import dnf5 in the tox environment,
even though the script can be run and the test will succeed.
Use `python3 -c "import libdnf5"` to decide if the script is runnable
instead of using `importlib`. This doesn't solve the problem of our
tests running python scripts in a different environment than the one (we
think) we are testing, but it will enable tests of osbuild-depsolve-dnf5
for now.
The go json serialize process takes a nil slice and converts that to a
'null' instead of an '[]' or leaving off the field. This means that the
json generated by python is not representative of what is output by
images/dnfjson and we have not been properly testing
osbuild-depsolve-dnf5
Testing dnf5 depsolving *also* requires that libdnf5 be present in the
environment, which is a separate problem that still needs to be fixed.
Given that the tests `test_depsolve{,_dnf5}` are identical except
the `command` extract them into a common test that is just parameterized.
This will also help to avoid drift between the two resolvers.
So that we see any error output during the tests in "realtime". With
subprocess check=True and capture_output=True on exit_code != 0 no
stderr as part of the exception by default so this change helps
seeing issues from depsolve-dnf more easily.
Extract make_dnf_scafolding as a helper, mostly so that the config_combos()
function is easier to read. It seems one core concept here is the iteration
of "combo[0]" and "combo[1]" so having them symetrical at the same indent
level feel easier to read to me.
Depsolver test that starts a temporary file server and queries it using
osbuild-depsolve-dnf.
Generates all combinations of repositories configured through the
depsolve-dnf request or the repositories directory and runs the test
cases. The results should be the same regardless of combination.
Test repos are defined with a fake gpg key on the request or repo config
and check if it is read correctly and attached to the repo configs in
the response. The name of the repo is appended to each repo's gpg key
so we can make sure that repo option values don't get swapped.
