[LTP] [RFC PATCH] Add simple Alpine container

[Petr Vorel]

Hi all,

...
> >> +++ 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.

+1. We would need at least some comment. If there are more things to say, it
might be useful to have a wiki page about container based testing (if you have
time and energy to write it).

> >> +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?

Sure, no problem. The real work is to identify these runtime dependencies.
I mean not libraries without development headers (headers does not take that
much size, thus I would not bother), but various other tools (e.g. ip,
ping, mkfs.*, useradd, quotacheck, e4crypt, exportfs, modprobe, rmmod, ...) Some
of them are installed on normal distro, but not all; for sure most of them
aren't installed in the default container.

> > 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
I'm not sure if that was a correct decision. Sure, it might be easier to
maintain scripts like this in the projects kirk runs (e.g. LTP, Kselftest),
but OTOH I see a benefit in having unified interface for all project
(or at least run these upstreamed scripts in kirk in unified way).

> to Kirk during test setup. It's just that those scripts don't live
> inside the Kirk repo.

+1

Kind regards,
Petr