[PATCH 1/1] Dockerfile: compile QEMU for Nokia N900 emulation
trini at konsulko.com
Tue Jul 14 00:56:08 CEST 2020
On Mon, Jul 13, 2020 at 11:27:40PM +0200, Heinrich Schuchardt wrote:
> On 13.07.20 19:20, Tom Rini wrote:
> > On Mon, Jul 13, 2020 at 07:10:46PM +0200, Heinrich Schuchardt wrote:
> >> For the Nokia N900 emulation we need a special QEMU version. Up to now we
> >> compile it in the Gitlab runner. By compiling it in Docker we can reduce
> >> the Gitlab job duration.
> >> To avoid naming conflicts the QEMU binary is stored as
> >> /opt/qemu/bin/qemu-system-n900.
> >> Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de>
> >> ---
> >> Dockerfile | 10 ++++++++++
> >> 1 file changed, 10 insertions(+)
> >> diff --git a/Dockerfile b/Dockerfile
> >> index 209e008..bc3cdee 100644
> >> --- a/Dockerfile
> >> +++ b/Dockerfile
> >> @@ -171,6 +171,16 @@ RUN git clone git://git.qemu.org/qemu.git /tmp/qemu && \
> >> make -j$(nproc) all install && \
> >> rm -rf /tmp/qemu
> >> +# Compile QEMU for Nokia N900 emulation
> >> +# Last working commit is 8f8d8e0796efe1a6f34cdd83fb798f3c41217ec1
> >> +RUN git clone https://git.linaro.org/qemu/qemu-linaro.git /tmp/qemu && \
> >> + cd /tmp/qemu && \
> >> + git checkout 8f8d8e0796efe1a6f34cdd83fb798f3c41217ec1 && \
> >> + ./configure --enable-system --target-list=arm-softmmu --disable-sdl --disable-gtk --disable-curses --audio-drv-list= --audio-card-list= --disable-werror --disable-xen --disable-xen-pci-passthrough --disable-brlapi --disable-vnc --disable-curl --disable-slirp --disable-kvm --disable-user --disable-linux-user --disable-bsd-user --disable-guest-base --disable-uuid --disable-vde --disable-linux-aio --disable-cap-ng --disable-attr --disable-blobs --disable-docs --disable-spice --disable-libiscsi --disable-smartcard-nss --disable-usb-redir --disable-guest-agent --disable-seccomp --disable-glusterfs --disable-nptl --disable-fdt && \
> >> + make -j$(nproc) && \
> >> + cp arm-softmmu/qemu-system-arm /opt/qemu/bin/qemu-system-n900 && \
> >> + rm -rf /tmp/qemu
> >> +
> >> # Create our user/group
> >> RUN echo uboot ALL=NOPASSWD: ALL > /etc/sudoers.d/uboot
> >> RUN useradd -m -U uboot
> > Azure and GitLab will pick this up, if we modify the job to link the
> > binary in. Travis will not, of course. But this feels like a bit of a
> > micro-optimization. The test job is 3-4 minutes currently. If we want
> Yes, time I am waiting for the tests that interest me. And sometimes it
> fails because the source repository is not available.
Right. But I assume you're doing unit testing locally and not via CI.
I would be quite open to moving this test to the rest of the QEMU based
group, in GitLab as that might result in the overall run completing
> > to reduce that, I think switching the test script to use $(nproc) rather
> > than 4 for all make jobs would be a bit better. Keeping all 3 CI
> This depends on the number of cores you have on Travis CI. Is this more
> than one?
I think so, yes.
> > scripts as close as possible is a goal we have to have I believe to
> > reduce the likelyhood of one CI failing when another passes and it being
> > the CI at fault rather than exposing a race condition in our code.
> says that you can use Docker images in Travis CI too.
> shows how to trigger tests inside a Docker image.
> I think the Docker route is the only way to minimize differences between
> the build systems.
I was under the impression that it would result in a fetch of the Docker
image every time and thus probably take much longer overall and possibly
require further splitting up of the Travis job.
Honestly and off-topic for this particular thread, at this point I'd
almost rather just drop Travis support and as much as I like the control
we have in GitLab the fact that every runner has occasional bouts of
random bad luck (DNS failures or jobs get stuck) means I wouldn't get
overly upset if we just used Azure as it's still quicker than Travis,
only a little slower than GitLab when it's fast and can be triggered by
anyone. It would however require custodians to setup yet another
account somewhere and that is a fairly big drawback (as I do expect
custodians to CI their tree before sending a PR and in turn that
blocking on the general Azure queue would be a big bottleneck I fear).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 659 bytes
Desc: not available
More information about the U-Boot