Re: [LTP] [RFC PATCH] Add simple Alpine container

[Richard Palethorpe <rpalethorpe@suse.de>]

Hello,

Petr Vorel <pvorel@suse.cz> writes:

> Hi all,
>
>> 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)
>> 2. The resulting container is quite large (possibly due to debug symbols)
>> 3. Where should we put container files and how should we name them?
>> 4. Making the slightest change results in a complete container rebuild
>
>> Note that SUSE publishes a TW container based on our packaging system:
>> https://build.opensuse.org/project/show/benchmark:ltp:devel
>> https://registry.opensuse.org/cgi-bin/cooverview?srch_term=project%3D%5Ebenchmark+container%3D.*
>
>> Also, for developing tests, it may be better to build the LTP outside
>> of a container then copy in the files.
>
>> +++ b/Containerfile
>> @@ -0,0 +1,35 @@
>> +FROM alpine:3.18 AS build
>
> Maybe we could use ARG and ENV to allow user to decide which distro to use.
> https://stackoverflow.com/questions/76091578/is-it-possible-to-use-an-environment-variable-in-the-from-instruction-of-a-docke
> This way we could use various scripts in ci.

Sounds good assuming it does not make the container file too
complicated. The scripts you made have been really helpful.

>
>> +ARG LTPROOT=/opt/ltp
>> +
>> +RUN mkdir /build
>> +WORKDIR /build
>> +COPY . /build
>> +RUN ./ci/alpine.sh
>> +RUN ./build.sh -p $LTPROOT -i
>> +
>> +FROM alpine:3.18
> Also here.
>
>> +ARG LTPROOT=/opt/ltp
>> +ARG KIRKROOT=/opt/kirk
>> +
>> +RUN apk add \
>> +            acl \
>> +            keyutils \
>> +            libaio \
>> +            libacl \
>> +            libcap \
>> +            libselinux \
>> +            libsepol \
>> +            libtirpc \
>> +            numactl \
>> +            openssl \
>> +            py3-msgpack
> This somehow emulates ./ci/alpine.sh (i.e. ./ci/alpine.sh has keyutils-dev,
> which should install also keyutils as a dependency). We could add a mechanism to
> ci scripts to install runtime dependencies (e.g. './ci/alpine.sh runtime' would
> install all runtime dependencies, './ci/alpine.sh runtime-syscalls' would
> install only runtime dependencies for syscalls).

How about, for now, just an optional 'runtime' flag that only installs
runtime deps?

>
> But better would be to move runtime dependencies to kirk. But unfortunately this
> part from original Cyril's perl based runltp-ng was not ported to new Andrea's
> python based runltp-ng/kirk.

Well we could also make an Alpine, Flatpack, Nix package or any number
of other ways to build LTP and install the deps. Andrea deliberately
chose to decouple that from Kirk. However you could pass the CI scripts
to Kirk during test setup. It's just that those scripts don't live
inside the Kirk repo.

>
> Kind regards,
> Petr
>
>> +
>> +COPY --from=build $LTPROOT $LTPROOT
>> +ENV LTPROOT=$LTPROOT
>> +ENV PATH=$LTPROOT/testcases/bin:$LTPROOT/bin:$PATH
>> +
>> +RUN mkdir -p $KIRKROOT
>> +COPY --from=build /build/tools/kirk $KIRKROOT
>> +
>> +RUN adduser -D -g "Unprivileged LTP user" ltp
>> +RUN su ltp


-- 
Thank you,
Richard.

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp