From: Marius Kittler <mkittler@suse.de>
To: ltp@lists.linux.it
Subject: Re: [LTP] [RFC PATCH] Add simple Alpine container
Date: Tue, 26 Sep 2023 12:51:12 +0200 [thread overview]
Message-ID: <2307102.ElGaqSPkdT@linux-9lzf> (raw)
In-Reply-To: <20230926090101.7565-1-rpalethorpe@suse.com>
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.
> 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.)
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2023-09-26 10:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-26 9:01 [LTP] [RFC PATCH] Add simple Alpine container Richard Palethorpe via ltp
2023-09-26 10:51 ` Marius Kittler [this message]
2023-09-27 7:00 ` Richard Palethorpe
2023-09-27 6:27 ` Petr Vorel
2023-09-27 7:29 ` Richard Palethorpe
2023-09-27 9:05 ` Petr Vorel
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=2307102.ElGaqSPkdT@linux-9lzf \
--to=mkittler@suse.de \
--cc=ltp@lists.linux.it \
/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