[LTP] [RFC PATCH] Add simple Alpine container

[Richard Palethorpe]

Hello,

Marius Kittler <mkittler@suse.de> writes:

> Am Dienstag, 26. September 2023, 11:01:01 CEST schrieb Richard Palethorpe via 
> ltp:
>> Can be built with `docker/podman build .`. Then run with `podman -it
>> run sh`. It contains Kirk in /opt/kirk. So `cd /opt/kirk && ./kirk -f
>> ltp --run-suite syscalls` will run some tests.
>> ---
>> 
>> Hello,
>> 
>> This builds and installs the LTP and Kirk inside an Alpine
>> container. The idea is to use a standard container workflow to build
>> and run the LTP from source. This helps with testing LTP itself and
>> running tests inside a container.
>> 
>> I'd like to add some container files to upstream to help with various
>> workflows.
>> 
>> The container has a number of problems:
>> 
>> 1. If the Git directory has build artifacts in it, these are copied
>>    into the container (.dockerignore may help)
>
> Doing an out-of-source-tree build might also help. Even just printing a 
> warning/error in case the repository has already been configured might be good 
> enough.

Good idea, perhaps check with Git that it is a clean
checkout. Especially because one could accidentally copy private files
into the container.

>
>> 3. Where should we put container files and how should we name them?
>
> Maybe just a subdirectory `container` and within that one subdirectory for 
> each container.
>
>> Also, for developing tests, it may be better to build the LTP outside
>> of a container then copy in the files.
>
> How would you do that? Relevant container-specific dependencies such as musl 
> are within the container. One had to expose the container's filesystem tree 
> somewhere in the regular filesystem and had to use that as prefix. That doesn't 
> seem like an easy way of doing things.
>
> By the way, to develop "[PATCH v1] Skip cgroup-related tests if `/sys/fs/
> cgroup` readonly" I simply started on a fresh Alpine container, invoked our CI 
> script for installing dependencies, followed the build instructions from the 
> README, committed the container for later use and then just continued 
> developing within the container as usual. (I was still using my editor from 
> outside the container. So the clangd integration still assumed glibc headers. 
> Maybe one could expose the container's filesystem on the host and change 
> include paths via `.clangd` to prefer musl headers from within the container.)

I'm not sure, you can export the LTP dir as a volume and use 'podman cp'
to copy the headers to somewhere on your host. This does feel hacky
though.

I suppose if clangd can run inside the container then it should be
possible to export its ports and connect to it from outside. However I
just have a checkout of the musl repo and manually search it.

-- 
Thank you,
Richard.