Add maintainer tag

[grisu48]

Adds a maintainer/owner tag to each test module that helps to identify the test/container owners.

This is a followup of https://confluence.suse.com/display/ENGCTNRSTORY/2025-03-11+-+BCI+Sync

[dcermak]

Do we really need this? I mean this looks to me more like that the AI team should get their own testsuite, given that the AI containers don't even play nicely with this one at all.

[grisu48]

Do we really need this? I mean this looks to me more like that the AI team should get their own testsuite, given that the AI containers don't even play nicely with this one at all.

I'm also happy with this solution.

On Tueday I raised the topic that it's difficult for QE to find the responsible person for a container, and this was an agreed solution for this issue.

If we agree that SUSE AI will have their own testsuite, it would not be necessary.

[dirkmueller]

There was a separate project to create testing coverage for SUSE AI. this testsuite is not used to validate the container source changes, it is used to validate the rebuilds due to dependency changes. as such it doesn't need to "play nicely" just figure out if the container are still starting.

[dirkmueller]

Adds a maintainer/owner tag to each test module that helps to identify the test/container owners.

@grisu48 this is confusing to me, I thought we agreed on adding a maintainer tag in https://gitlab.suse.de/qac/container-release-bot/-/tree/main/containers?ref_type=heads instead where all the testing gets in one place ? why would you want to have that in BCI-tests when not all containers that the container-release-bot/openqa is handling is going via BCI-tests?

[dcermak]

There was a separate project to create testing coverage for SUSE AI. this testsuite is not used to validate the container source changes, it is used to validate the rebuilds due to dependency changes. as such it doesn't need to "play nicely" just figure out if the container are still starting.

It does not play nicely insofar that it doesn't integrate into our development workflow at all. Currently we cannot test that we don't accidentally break the AI tests with a source change. It hasn't happened yet, but I'm not too thrilled about that eventually happening. Also it makes testing AI related contributions like #752 a major pain.

[dirkmueller]

It does not play nicely insofar that it doesn't integrate into our development workflow at all. Currently we cannot test that we don't accidentally break the AI tests with a source change.

This is the same for anything else that is built in IBS, like the LTSS containers, and the same fix can be applied (running the testsuite against TARGET=ibs-released so that we can at least validate the test code still working fine. It wasn't possible when the code was initially introduced due to chicken-and-egg situation but now this can be easily done.

[grisu48]

Closing this, we need to find a different solution elsewhere.