public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Richard Palethorpe <rpalethorpe@suse.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH] Add simple Containerfile
Date: Thu, 28 Sep 2023 20:11:24 +0200	[thread overview]
Message-ID: <20230928181124.GA309263@pevik> (raw)
In-Reply-To: <20230928104458.12115-1-rpalethorpe@suse.com>

Hi Richie,

I suppose this is v2 of "[RFC] Add simple Alpine container" [1], thus I set [1]
in patchwork as superseded.

This LGTM, thanks! Minor comments below.

Reviewed-by: Petr Vorel <pvorel@suse.cz>

> This adds a regular container (or Docker) file which builds LTP from
> source. This is initially intended for testing the LTP itself.

> The resulting container has just the LTP installation and runtime
> dependencies. However it is still quite large, probably due to debug
> symbols.

> The container can be built with a command like:

> podman build -t tumbleweed/ltp \
>        --build-arg PREFIX=registry.opensuse.org/opensuse/ \
>        --build-arg DISTRO_NAME=tumbleweed \
>        --build-arg DISTRO_RELEASE=20230925 .

> Or just

> podman build -t alpine/ltp .

> It contains Kirk in /opt/kirk. So

> cd /opt/kirk && ./kirk -f ltp -r syscalls

> will run some tests.

> Note a much smaller container can be found at:
> https://registry.opensuse.org/cgi-bin/cooverview?srch_term=project%3D%5Ebenchmark+container%3D.*
> This is created with SUSE's build system which does not use container files

> Signed-off-by: Richard Palethorpe <rpalethorpe@suse.com>
> Cc: Petr Vorel <pvorel@suse.cz>
> Cc: Marius Kittler <mkittler@suse.de>
> ---

> RFC comments:
>     * Add git clean -fdX which should remove any build artifacts
>       this is different from the suggestion of just doing a check. I just
>       found it easier to remove the build files.
FYI what we do in release scripts, is to do a local clone to a different
directory [2]:
git clone ltp ltp-full-YYYYMMDD

Not sure what is faster.

>     * Added seperate alpine and tumbleweed runtime scripts. Again it's
>       different from the suggestion just because it's easier to add
>       seperate scripts than adding a switch
+1

But maybe put it into container directory, because it's not used in GitHub CI?

>     * Obviously a number of distros are missing runtime scripts. They can
>       be added when someone is motivated to do so.

+1

> diff --git a/.dockerignore b/.dockerignore
> new file mode 100644
> index 000000000..bbcd7072f
> --- /dev/null
> +++ b/.dockerignore
> @@ -0,0 +1 @@
> +Containerfile
> diff --git a/Containerfile b/Containerfile
> new file mode 100644
> index 000000000..2f8192c3b
> --- /dev/null
> +++ b/Containerfile
> @@ -0,0 +1,32 @@
> +ARG PREFIX=docker.io/
> +ARG DISTRO_NAME=alpine
> +ARG DISTRO_RELEASE=3.18
> +
> +FROM $PREFIX$DISTRO_NAME:$DISTRO_RELEASE AS build
> +ARG LTPROOT=/opt/ltp
> +ARG DISTRO_NAME=alpine
> +ARG DISTRO_RELEASE=3.18
> +
> +RUN mkdir /build
> +WORKDIR /build
> +COPY . /build
> +RUN ./ci/${DISTRO_NAME}.sh
> +RUN git clean -fdX
> +RUN ./build.sh -p $LTPROOT -i
> +
> +FROM $PREFIX$DISTRO_NAME:$DISTRO_RELEASE
> +ARG LTPROOT=/opt/ltp
> +ARG KIRKROOT=/opt/kirk
> +ARG DISTRO_NAME=alpine
> +
> +COPY --from=build /build/ci/${DISTRO_NAME}-runtime.sh $LTPROOT/runtime-deps.sh
> +RUN $LTPROOT/runtime-deps.sh
> +
> +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
> +
> +USER ltp
> diff --git a/ci/alpine-runtime.sh b/ci/alpine-runtime.sh
> new file mode 100755
> index 000000000..e4941f329
> --- /dev/null
> +++ b/ci/alpine-runtime.sh
> @@ -0,0 +1,16 @@
> +#!/bin/sh -eux

nit: out of curiosity, why -u (fail unset variables and parameters)?
> +
> +apk add \
> +        acl \
> +        keyutils \
> +        libaio \
> +        libacl \
> +        libcap \
> +        libselinux \
> +        libsepol \
> +        libtirpc \
> +        numactl \
> +        openssl \
> +        py3-msgpack

I'd add more runtime packages (at least for syscalls).  If I manage next week to
test this I might ask for more packages, but let's start with this

Kind regards,
Petr

[1] https://patchwork.ozlabs.org/project/ltp/patch/20230926090101.7565-1-rpalethorpe@suse.com/
[2] https://patchwork.ozlabs.org/project/ltp/patch/20230927202121.300325-6-pvorel@suse.cz/

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

  reply	other threads:[~2023-09-28 18:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-28 10:44 [LTP] [PATCH] Add simple Containerfile Richard Palethorpe via ltp
2023-09-28 18:11 ` Petr Vorel [this message]
2023-09-29  7:42   ` Richard Palethorpe
2023-09-29  8:15     ` Petr Vorel
2023-09-29  9:15       ` Richard Palethorpe
2023-09-29  9:37         ` Petr Vorel
2023-10-04 12:28 ` Marius Kittler
2023-10-05  8:07   ` Richard Palethorpe
2023-10-10 11:28 ` Andrea Cervesato via ltp

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230928181124.GA309263@pevik \
    --to=pvorel@suse.cz \
    --cc=ltp@lists.linux.it \
    --cc=rpalethorpe@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox