All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Korsgaard <peter@korsgaard.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] support/testing: add docker / docker-compose tests
Date: Mon, 04 Feb 2019 21:20:27 +0100	[thread overview]
Message-ID: <87a7jbs3uc.fsf@dell.be.48ers.dk> (raw)
In-Reply-To: <20190204195345.6494760a@windsurf> (Thomas Petazzoni's message of "Mon, 4 Feb 2019 19:53:45 +0100")

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes:

Hi,

 > On Mon,  4 Feb 2019 17:55:57 +0100
 > Peter Korsgaard <peter@korsgaard.com> wrote:

 >> Build for x86-64 as public containers in general are only available for
 >> x86-64.  Docker needs a number of kernel options enabled, so use a custom
 >> kernel config based on the qemu one.

 > Do you need to duplicate the kernel config entirely, or can you use
 > board/qemu/x86_64/linux.config + a fragment ?

I didn't really look closely. I recently setup docker / docker-compose at
$WORK, so I based the linux config on that.

I can have a look at basing it on the qemu config, but that means that
we have to be a bit careful when bumping the qemu config, so I'm not
sure if it makes sense.


 >> Docker needs entropy at startup, so enable the virtio-rng-pci device to
 >> expose entropy to the guest.  The default RAM amount (128M) is not enough to
 >> run docker / docker-compose, so bump to 512MB.

 > Wow. Go is efficient :)

;)

 >> diff --git a/support/testing/conf/docker-compose.yml b/support/testing/conf/docker-compose.yml
 >> new file mode 100644
 >> index 0000000000..49ff2677da
 >> --- /dev/null
 >> +++ b/support/testing/conf/docker-compose.yml
 >> @@ -0,0 +1,4 @@
 >> +version: '3'
 >> +services:
 >> +  busybox:
 >> +    image: "busybox:latest"

 > Is conf/ really the right place for this ? Don't we have some other
 > place to store the per-tests artifacts that go on the target ? I don't
 > think we have a good organization for this at the moment, so this will
 > do for now.

Indeed. We have a number of more-or-less random files under conf/, and
then E.G. tests/package/test_python_*.py stores files for the target
also under tests/package/sample_*.py

I can move the files under tests/package if you prefer, but I'm not sure
if that is really cleaner.

-- 
Bye, Peter Korsgaard

  reply	other threads:[~2019-02-04 20:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-04 16:55 [Buildroot] [PATCH] support/testing: add docker / docker-compose tests Peter Korsgaard
2019-02-04 17:11 ` Matthew Weber
2019-02-05  0:39   ` ricardo.martincoski at gmail.com
2019-02-05  9:18     ` Peter Korsgaard
2019-02-05  9:13   ` Peter Korsgaard
2019-02-04 18:53 ` Thomas Petazzoni
2019-02-04 20:20   ` Peter Korsgaard [this message]
2019-02-05  0:47     ` Ricardo Martincoski
2019-02-05 22:05 ` Peter Korsgaard
2019-02-05 22:08   ` Matthew Weber

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=87a7jbs3uc.fsf@dell.be.48ers.dk \
    --to=peter@korsgaard.com \
    --cc=buildroot@busybox.net \
    /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.