From: Julien Olivain <ju.o@free.fr>
To: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: buildroot@buildroot.org,
Raphael Pavlidis <raphael.pavlidis@gmail.com>,
Christian Stewart <christian@aperture.us>
Subject: Re: [Buildroot] [PATCH 9/9 v3] package/podman: new package
Date: Sat, 08 Mar 2025 23:03:24 +0100 [thread overview]
Message-ID: <e4c6b89d497cd5586d63bfbce4d0baf6@free.fr> (raw)
In-Reply-To: <Z8wrSOraiHBxlQWD@landeda>
Hi Yann,
On 08/03/2025 12:34, Yann E. MORIN wrote:
> Julien, All,
>
> On 2025-03-07 19:55 +0100, Julien Olivain spake thusly:
>> On 01/03/2025 16:05, Yann E. MORIN wrote:
>> > Podman is a container manager not unlike Docker, but is daemon-less.
> [--SNIP--]
>> > + self.assertRunOk("useradd -d /home/foo -m -s /bin/sh -u 1000
>> > foo")
>> It would be nice to keep tests idempotent. This can be useful
>> while debugging tests, and avoid rebuilding everything at each
>> attempt.
>
> You know that you can just remove the "build-done" filestamp in the
> test
> build directory, to just rebuild the image and not the whole thing,
> right? ;-)
>
> $ rm -f run-tests/TestSkopeo/build-done
>
>> It is even more useful in tests with a long build time
>> like this one.
>
> Well, you'd get other issues as well in case the tests are failing: if
> the test fails to remove the images from local storage, then restarting
> the test will fail even earlier, as it expects an empty local storage
> to
> start with...
>
> Furthermore, the virtual machine is abruptly terminated when the test
> ends (the qemu process is killed without letting the VM a chance to
> shutdown), the filesystem will be inconsistent, leaving all sorts of
> false negative (or positives) if restarting the test anyway (e.g.
> removing the images from local storage, even is sucessful, might not
> have had a chance to hit the disk yet).
>
>> If possible, could you improve the test to make sure it can run
>> at least two time in a row with the run-tests "-k" option, please?
>> For example, with a construct like:
>> id -u foo || useradd ... foo
>
> Sorry, but this is not a good idea I believe. The tests should be run
> from a clean build, or at the very least from a clean image (which is
> easy to do, see above).
>
> In retrospect, I believe the build should always be restarted to always
> start the test from a clean image, and so the "build-done" filestamp is
> in fact counter-productive: we _want_ to rebuild the rootfs image
> before
> starting tests.
>
>> There is possibly few other places that might need cleanup too.
>
> There are so many other tests that are probably not idempotent either,
> unfortunately, as soon as they do not use the CPIO or do not use a
> read-only persistent storage.
>
> For example, the docker-compose test is not idempotent, as the image
> will remain on the disk (but OK, the second run would not fail, just
> the
> download would not happen, which means though that the second run would
> not test the same thing as the first run).
>
> So, I am not very inclined in making this one test idempotent.
>
> Instead, I think we should really just get rid of build-done.
You are right. It is probably the "run-tests -k" command which might
need to be idempotent (rather than the test itself).
So, forget about my change suggestions in this test. I'm taking a
note about a possible future improvement on run-tests, instead.
> Thanks for the review! :-)
>
> Regards,
> Yann E. MORIN.
Best regards,
Julien.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
prev parent reply other threads:[~2025-03-08 22:03 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-01 15:05 [Buildroot] [PATCH 0/9 v3] package/podman: new package (branch yem/podman) Yann E. MORIN
2025-03-01 15:05 ` [Buildroot] [PATCH 1/9 v3] support/testing: set date in emulated machine Yann E. MORIN
2025-03-07 18:49 ` Julien Olivain
2025-03-08 11:07 ` Yann E. MORIN
2025-03-08 21:51 ` Julien Olivain
2025-03-01 15:05 ` [Buildroot] [PATCH 2/9 v3] package/shadow: install to staging for subids Yann E. MORIN
2025-03-07 13:15 ` Raphael Pavlidis
2025-03-01 15:05 ` [Buildroot] [PATCH 3/9 v3] package/conmon: depends on systemd when enabled Yann E. MORIN
2025-03-01 15:05 ` [Buildroot] [PATCH 4/9 v3] package/slirp4netns: needs TUN support in the kernel Yann E. MORIN
2025-03-07 13:20 ` Raphael Pavlidis
2025-03-01 15:05 ` [Buildroot] [PATCH 5/9 v3] package/skopeo: add target variant Yann E. MORIN
2025-03-01 15:05 ` [Buildroot] [PATCH 6/9 v3] package/cgroupfs-mount: tweak the kernel config Yann E. MORIN
2025-03-01 15:05 ` [Buildroot] [PATCH 7/9 v3] package/cgroupfs-v2-mount: new package Yann E. MORIN
2025-03-01 15:05 ` [Buildroot] [PATCH 8/9 v3] package/netavark: " Yann E. MORIN
2025-03-01 15:05 ` [Buildroot] [PATCH 9/9 v3] package/podman: " Yann E. MORIN
2025-03-07 13:40 ` Raphael Pavlidis
2025-03-07 19:38 ` Christian Stewart via buildroot
2025-03-08 11:02 ` Yann E. MORIN
2025-03-08 11:00 ` Yann E. MORIN
2025-03-09 8:30 ` Yann E. MORIN
2025-03-09 22:14 ` Yann E. MORIN
2025-03-07 18:55 ` Julien Olivain
2025-03-08 11:34 ` Yann E. MORIN
2025-03-08 22:03 ` Julien Olivain [this message]
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=e4c6b89d497cd5586d63bfbce4d0baf6@free.fr \
--to=ju.o@free.fr \
--cc=buildroot@buildroot.org \
--cc=christian@aperture.us \
--cc=raphael.pavlidis@gmail.com \
--cc=yann.morin.1998@free.fr \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.