I don't think it's a good practice and it makes the role unusable for non-root users

FWIW, the test specification mandates running the tests as root. The tests can then move to appropriate permissions or perform necessary actions as root. But as you pointed out use of this capability can be avoided.

If the packages can't be installed on a target system, can be the role changed to download rpm and extract them on a target system?

That's a good idea and worth a patch. Are you interested in making a pull request?

FWIW, the test specification mandates running the tests as root. The tests can then move to appropriate permissions or perform necessary actions as root. But as you pointed out use of this capability can be avoided.

Do you know why it's MUST to run a test playbook on a testing system as root?
It's doable on automatic testing systems, but it makes tests harder to use/run for regular users/maintainers. And even for automatic systems a testing playbook ran as root which uses delegate_to: localhost could break the testing system.

If the packages can't be installed on a target system, can be the role changed to download rpm and extract them on a target system?

That's a good idea and worth a patch. Are you interested in making a pull request?

I can't promise it right now. Is there a reason why the role installs packages to localhost instead of to a target system? Would it be acceptable just to drop delegate_to options from the role and install beakerlib related packages directly to a target system?

I hit this issue when I tried to run tests from https://src.fedoraproject.org/rpms/libselinux/pull-request/1 on my system using:

ansible-playbook -v -i /usr/share/ansible/inventory/standard-inventory-qcow2 bootstrap.yml tests.yml

Given that I ran it as non-root user and tests.yml uses standard-test-beakerlib role and it tried to install some repositories and packages on my system, the test failed.

Do you know why it's MUST to run a test playbook on a testing system as root?

Because for most test subjects, root is required to either:

• Run the test subject directly on the machine (such as an RPM or Repo test subject).
• Access the service used to launch the test subject (such as Docker)

In addition, tests themselves can create users and drop privileges, but escalating privileges to root in order to test root-only aspects of a package or feature would be challenging or impossible.

I would suggest launching and developing tests inside of a virtual machine. @merlinm Did you have any such best practices for developing tests, with a vagrant virtual machine or similar?

I do not have any such best practices. (I have done very little test development--but I've done a lot of porting/migrating tests from others.) But I can say I've done all of my work inside VMs where I have root access--for reasons such as this along with the ability to easily snapshot/rollback if things go awry.

I see. I can use a vm for now.

For future it would be great if roles didn't require root on localhost and didn't touch it at all. Localhost root would be required only by a test using a role if some privilege operation were needed on localhost, e.g. to launch docker service.

https://docs.fedoraproject.org/en-US/ci/standard-test-interface/#_invocation
Closing this issue.