QA » openQA Project

Here's what I have so far:

• os-autoinst-wheel-launcher is a wheel. I don't currently have the priviledges to add this to os-autoinst in case we want that.
• os-autoinst/os-autoinst#2004 teaches isotovideo to grab wheels if they're being used.
• os-autoinst/os-autoinst-distri-openQA#82 makes use of the new wheel

I adjusted the code to not refer to x11 since there's no x11 involved and also to use %args the way we usually do in test functions.

Note that both "plugins" and "wheels" are being used. Feel free to let it sink in and make a case for one or the other.

I think it looks awesome. My suggestions on the global scale:

1. Follow https://metacpan.org/pod/Perl::Critic::Policy::NamingConventions::Capitalization, so OpenQA::Wheel::Launcher, not OpenQA::Wheel::launcher
2. It's crucial that we provide self-tests for wheels. So how aobut a simple Test::Most test case in https://github.com/kalikiana/os-autoinst-wheel-launcher which mocks everything outside the repo

okurz wrote:

1. Follow https://metacpan.org/pod/Perl::Critic::Policy::NamingConventions::Capitalization, so OpenQA::Wheel::Launcher, not OpenQA::Wheel::launcher
2. It's crucial that we provide self-tests for wheels. So how aobut a simple Test::Most test case in https://github.com/kalikiana/os-autoinst-wheel-launcher which mocks everything outside the repo

+1 for both. And then run the tests in a GitHub Action.

The our @EXPORT = qw(start_gui_program); in the wheel repo is a bad idea though, it should be our @EXPORT_OK = qw(start_gui_program);. Because if all wheels are using default exports it will be very very hard to keep track of which function comes from which wheel.

Points discussed in the unblock:

• Add v: v0.1 to the wheels.yaml (we want this to be a string to avoid running into funny behavior once we get to e.g. v0.10)
• Stick to the term wheels because both modules and plugins already have other meanings in openQA
• May want needles and metadata in wheels in the future but those don't need to be specified now

• Apparmor needs to expose podman: https://github.com/os-autoinst/openQA/pull/4606 (Error documented as part of #109235)

okurz wrote:

If there would be more people available right now I would ask for someone else to help you. Let's look into this after the Easter Break. If done after that, good, if not we can reconsider priorities and doing a mob session.

Turns out the mocking is proving to be challenging. After several attemps I moved the relevant unit tests into another PR. Maybe it's worth looking at #81899 in this context?

https://github.com/os-autoinst/os-autoinst/pull/2004 merged. You can now continue with https://github.com/kalikiana/os-autoinst-wheel-launcher and https://github.com/os-autoinst/os-autoinst-distri-openQA/pull/82 I guess?

okurz wrote:

https://github.com/os-autoinst/os-autoinst/pull/2004 merged. You can now continue with https://github.com/kalikiana/os-autoinst-wheel-launcher and https://github.com/os-autoinst/os-autoinst-distri-openQA/pull/82 I guess?

Next one up is picking up wheel "lib" folders and "tests" folders. I found a way to cover it without having to run tests by relying on the fact that Perl executes the wheel code via use even when evaluating just the test schedule. This is also why I'm including support for picking up tests now because it turns out it's easier to unit test both.

I also need to find out how to create a wheel repo in https://github.com/orgs/os-autoinst so we don't need to rely on a personal repo of mine for that. Probably need to find someone with sufficient permissions.

cdywan wrote:

Next one up is picking up wheel "lib" folders and "tests" folders.

The branch was merged. I'm now checking that a new container is built since the self-tests use devel/openqa/containers/isotovideo:qemu-x86. Also seeing if it's easy enough to publish that as a re-usable action to avoid having to copy this in the future (but that's not required and won't block this ticket)

cdywan wrote:

cdywan wrote:

Next one up is picking up wheel "lib" folders and "tests" folders.

The branch was merged. I'm now checking that a new container is built since the self-tests use devel/openqa/containers/isotovideo:qemu-x86. Also seeing if it's easy enough to publish that as a re-usable action to avoid having to copy this in the future (but that's not required and won't block this ticket)

Brief update, it didn't seem like the container was updated and I confirmed it wasn't with the latest build still being from 14-Jul-2022 14:48. I couldn't find a way to re-trigger so I toggled x86-64 which seems to work, or at least OBS said it's "recomputing".

cdywan wrote:

[...] Also seeing if it's easy enough to publish that as a re-usable action to avoid having to copy this in the future (but that's not required and won't block this ticket)

https://github.com/kalikiana/isotovideo-action

After a bit of reading I found a way to leverage native docker support so the most simple case becomes - uses: actions/isotovideo-action@main.

Verification run: https://openqa.opensuse.org/tests/2494129

https://github.com/os-autoinst/os-autoinst-distri-openQA/pull/82 merged. I see AC2 as covered, AC1 still open, see https://github.com/os-autoinst/os-autoinst-distri-openQA/blob/master/lib/susedistribution.pm

okurz wrote:

https://github.com/os-autoinst/os-autoinst-distri-openQA/pull/82 merged. I see AC2 as covered, AC1 still open, see https://github.com/os-autoinst/os-autoinst-distri-openQA/blob/master/lib/susedistribution.pm

https://github.com/os-autoinst/os-autoinst-distri-openQA/pull/96

merged. Please put a comment into the parent epic about what you think is the conclusion of this ticket and next steps and then resolve