Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Review tests in microdnf directory #1579

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

kontura
Copy link
Contributor

@kontura kontura commented Oct 23, 2024

A lot of the tests are duplicate to regular dnf5 tests but they are run through the microdnf command.

The tests don't need to be separated anymore because dnf5 supports
and uses installroot when running them.

Stderr checking had to be amended for a couple reinstall tests.
One install test (Install an RPM without null lines) was dropped.
- since dnf5 supports installroot we can drop the `@no_installroot` tag
- `microdnf transaction is` had to be changed to `transaction is
  following` because the transaction formatting is different
- `upgraded` Actions were dropped because they are not tracked in dnf5
  step
- stderr and stdout outputs had to be modified on several places
- Fix `Scenario: multiline config for gpg works with local repo` by
  adding proper path to repos (the test wasn't running before)
- vars.feature: contained a test where installroot path was included
  twice (one automatically and one manually).
- protect-running-kernel.feature: needs to exclude `dnf-ci-obsolere` in
  the background otherwise the obsolete package is installed right away.
  Apparently original microdnf didn't do that (but both old dnf and dnf5
  do take the obsolete into account on install).
@pkratoch
Copy link
Contributor

Is it really worth it to keep the microdnf tests in the separate microdnf directory if it's just an alias for the dnf5 command? In past, we had run tests explicitly with "dnf", "dnf-3" and "yum", maybe it was even possible to switch the command for all the tests, I am not sure exactly. But having the test at one place and only switching the command name seems better than to have a somewhat duplicate sets of tests. I can imagine it might be a lot of work to change it, but it would be more maintainable later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants