Re: RFC: rocm-autopkgtest-helper

[Christian Kastner <ckk@debian.org>]

Some things I noticed when working on the implementation:

On 2024-10-12 13:51, Christian Kastner wrote:
>  $ rocm-autopkgtest-helper --help
> usage: rocm-autopkgtest-helper [options] PATH [PATH ...]

> For any PATH that is a directory, runs all executables (chmod +x) in 
> that directory.

I *think* this interface might be the wrong one, as it makes it
impossible to pass options to the test command.

So the possible interfaces seem to be:

(A) The originally proposed interface: each argument is either a test,
    or a directory of tests:

      Test-Command: rocm-autopkgtest-helper /tests/test1 /tests/test2

    If options are to be passed to a one or more of the test commands,
    they would need to be wrapped in a custom script:

      Test-Command: rocm-autopkgtest-helper /tests/test1 debian/tests/test2-wrapper

(B) One test per invocation, with arbitrary options

    Test-Command: rocm-autopkgtest-helper /path/to/test --output foo.xml --skip BadTest

    The downside is that one can no longer specify a directory, but a
    wrapper could solve this.

(C) Adding a new option --test-args

    Test-Command: rocm-autopkgtest-helper --test-args="--output foo.xml" /tests/test1 /tests/test2

    Though this means either one --test-args for all tests, or parsing
    --test-args1, --test-args2, etc. I think this is a no-go.

I'm leaning towards (B) because when I think of the autopkgtests I
implemented, it was more typical for one test call to accept options,
than to call more than one test (runner). Hence, if a wrapper cannot
be avoided, then best to relegate it to the rarer use case.

>   Note: you can actually leave out the needs-sudo restriction, but this
>   disables certain features used on ci.rocm.debian.net. The Debian ROCm Team
>   would appreciate it if you would specify needs-sudo.

I believe I may be able to avoid needs-sudo.

It's needed on QEMU so that the 'debci' user, which runs the test, can
read dmesg. But I can simply modify the testbed build instead, and have
dmesg unrestricted within VMs. I see no meaningful security downside to
this.

It's also needed for reading firmware but here, too, a simple worarkound
exists, namely bind-mounting /sys/kernel/debug/dri to somewhere 'debci'
can read it, like /tmp/dri.

The nice thing is that both of this would also work for podman workers,
where we currently don't save this important information.

Best,
Christian