buildroot/support/docker, branch 2019.02-op-build

support/docker: use the distro-provided flake8

2018-06-17T18:54:02+00:00

Currently, we install flake8 and its dependencies via pip. We tried to be reproducible by pinning the version of those python packages, but we did forget quite a few of them, and thus some dependencies for flake8 are installed as uncontrolled versions. Furthermore, before we install flake8 and its dependencies, we forcibly update pip, setuptools, and wheels packages to their latest versions. This explicitly breaks reproducibility. While we could enforce a specific version of all those packages and still grab them from PyPI, we can simply grab them from the distribution-provided packages instead. Since we're using a pinned version of stretch, this already guarantees we'll reproducibly get the same versions over and over again. Besides, we just need to list flake8 as a package to install to automatically get all its dependencies (again, in a reproducible way). This has the slight unfortunate drawback of downgrading flake8 to version 3.2.1, from version 3.5.0, as well as downgrading a few of flake8's dependencies, as noticed by Ricardo: http://lists.busybox.net/pipermail/buildroot/2018-May/222376.html However, as Ricardo said, there isn't "any serious limitation of this old version, the release notes for a version in the between mentions 'Dramatically improve the performance' but we have a limited number of scripts and running on Gitlab for all of them still takes less than 5 minutes". Signed-off-by: "Yann E. MORIN" Cc: Ricardo Martincoski Acked-by: Ricardo Martincoski Signed-off-by: Thomas Petazzoni

support/docker: sort the list of installed packages

2018-06-17T18:53:53+00:00

As suggested in the docker best practices [0], order the package list alphabetically, and list only one package per line. This will be much usefull later, we need to update the list of installed packages, like adding new ones for example. [0] https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#sort-multi-line-arguments Signed-off-by: "Yann E. MORIN" Cc: Ricardo Martincoski Reviewed-by: Ricardo Martincoski Signed-off-by: Thomas Petazzoni

support/docker: run apt-get update and apt-get install in two RUNs

2018-06-03T18:31:20+00:00

In commit 7517aef4d (support/docker: limit the number of layers), we reduced the number of layers by coalescing multiple RUN commands into less commands. In doing so, we especially coalesced "apt-get update" with "apt-get install". However, the distribution we used is a pinned version of stretch, so we know that running apt-get update will always yield the same apt database. If we split the two apt-get commands, then we can re-use any local intermediate image when we need to update the list of packages to install; this helps quite a bit when testing the docker files over and over again, with just slight variants in the packages list. Signed-off-by: "Yann E. MORIN" Cc: Ricardo Martincoski Cc: Peter Korsgaard Reviewed-by: Ricardo Martincoski Signed-off-by: Thomas Petazzoni

support/dockerfile: install flake8

2018-03-13T21:32:36+00:00

Use the latest version of the tool because it is actively maintained. But use a fixed version of the tool and its dependencies to get stable results. It can be manually bumped from time to time. Before installing any Python packages, ensure pip, setuptools, and wheel are up to date as recommended in the docs [1]. [1] https://packaging.python.org/tutorials/installing-packages/ Signed-off-by: Ricardo Martincoski Cc: Arnout Vandecappelle Cc: Peter Korsgaard Cc: Thomas Petazzoni Cc: Yann E. MORIN Acked-by: "Yann E. MORIN" Signed-off-by: Peter Korsgaard

support/dependencies: add check for c++ multilib

2018-02-06T16:21:09+00:00

Some packages build C++ 32bits host-tools and need the g++-multilib to be installed on the build machine. As example, qt5webengine builds a C++ host-tool when target is 32bits. Add the check for g++-multilib to the dependencies script; and update the Dockerfile to install g++-multilib package. Signed-off-by: Gaël PORTAY Signed-off-by: Thomas Petazzoni

support/dockker: create and push tagged images

2018-02-04T20:58:59+00:00

Currently, we refer to the latest version of the image, which means we can't guarantee any reproducibility. Also, it measn we can't have a separate images for the maintenance branches (especially the LTS) and master. Update the comment in the Dockerfile to create and push tagged images. Signed-off-by: "Yann E. MORIN" Cc: Arnout Vandecappelle Cc: Peter Korsgaard Signed-off-by: Peter Korsgaard

support/docker: use a fixed Debian snapshot

2018-02-04T20:57:53+00:00

Since we're now using a specific base image tag, we need to also use a specific, stable repository to get additional packages from for this image. As such, use the Debian snapshot that matches the base image. Signed-off-by: "Yann E. MORIN" Cc: Arnout Vandecappelle Cc: Peter Korsgaard Signed-off-by: Peter Korsgaard

support/docker: use a known base distribution

2018-02-04T20:57:37+00:00

Currently, we are using debian:stable, which is subject to change with time, as new stable versions of Debian are released/updated. Use the latest tagged stable release, stretch-20171210 as of today, as the base distribution to use. This will ease reproducible builds in the future. Signed-off-by: "Yann E. MORIN" Cc: Arnout Vandecappelle Cc: Peter Korsgaard Signed-off-by: Peter Korsgaard

support/docker: don't be silent when setting up

2018-02-04T20:53:02+00:00

This image is not built very often, and when it is, it is important to see what's going on, so don't be silent when installing packages from the distro, and since that can take a bit of time it thus serves as progress report... Signed-off-by: "Yann E. MORIN" Cc: Arnout Vandecappelle Signed-off-by: Peter Korsgaard

support/docker: limit the number of layers

2018-02-04T20:52:03+00:00

The official documentation [0] suggests limiting the number of layers generated from a dockerfile. A layer is created for each RUN (and COPY and ADD) command. But we are only ever interested in the final image, so the intermediate layers are useless to us. Limit the number of RUN commands to limit the number of generated layers. [0] https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#minimize-the-number-of-layers Reported-by: Peter Korsgaard Signed-off-by: "Yann E. MORIN" Cc: Peter Korsgaard Cc: Arnout Vandecappelle Signed-off-by: Peter Korsgaard