Re: [LTP] [PATCH] Add simple Containerfile

[Richard Palethorpe <rpalethorpe@suse.de>]

Hello,

Marius Kittler <mkittler@suse.de> writes:

>> 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.
>
> It would likely make sense to add a section with these information in the 
> README as well.

I agree, but I think I will be doing some more work with containers with
Kirk and LTX. So I would prefer to document it after I know more about
the best workflow.

>
> I'm also wondering about the workflow of making changes (e.g. to a single test) 
> and then re-compiling and re-running the specific test. Maybe that's also worth 
> considering/documenting.

TBH I don't have a good workflow for that. I know that we can mount the
source in a volume. However we probably need to move the build out of
the tree. I'd be interested in suggestions.

>
>> 
>> Note a much smaller container can be found at:
>> https://registry.opensuse.org/cgi-bin/cooverview?srch_term=project%3D%5Ebenc
>> hmark+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.
>
> Where we document the usage of the container we should also document that 
> it'll do this kind of cleanup so there are no surprises.

To be clear this only happens inside the container and *should* only
remove things covered by .gitignore (i.e. build artifacts). So does it
need documenting in that case?

>
>>     * 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
>>     * Obviously a number of distros are missing runtime scripts. They can
>>       be added when someone is motivated to do so.
>> 
> …
>> +RUN mkdir /build
>> +WORKDIR /build
>> +COPY . /build
>> +RUN ./ci/${DISTRO_NAME}.sh
>> +RUN git clean -fdX
>> +RUN ./build.sh -p $LTPROOT -i
>> +
>
> It might make sense to combine consecutive run commands (see
> https://github.com/hadolint/hadolint/wiki/DL3059).

I think this depends on exactly how caching works and where the best
place to put git clean is. Ideally we only want to run the ci script
when the dependencies change.

Maybe we should also split the COPY, to make sure the container
runtime can detect which files have changed.

More importantly I think this relates to your comment on workflow for
changing a single test. Ideally we should be able to change and compile
a single test without doing a bunch of unecessary work. Right now I am
not sure how to do that?

-- 
Thank you,
Richard.

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