6 Sep
2017
6 Sep
'17
3:05 p.m.
Hi Andre,
On Wed, Sep 06, 2017 at 02:05:16PM +0200, André Boddenberg wrote:
no, every 'docker run' job would be preceeded with a 'docker build',
which
would either rebuild the image if needed (based on the "ADD" patch URL)
or simply use the most recent image from the cache.
There would be one image/Dockerfile that builds libosmo* in it at
'docker build' time, and which then is used with 'docker run' to build
the specific application for which you're doing build testing, e.g.
osmo-bsc or osmo-hlr.
The build test at 'docker run' time would then happen completely inside
the docker tmpfs overlay and is expected to run super quick,
particularly given that build-2 has 64GB of RAM. If we want to keep
some artefacts, then those would have to be copied (e.g. during "make
install" to a bind-mount/volume).
> This line fetches the given URL (in this case
the latest patch on that
> branch) and considers the docker image as unchanged if that URL shows the
> same as last time. As soon as a new patch shows, things are rebuilt.
Great idea! So, the hourly/nightly jobs would "docker build..."
instead of "docker run..."? Will there be one Dockerfile per each branch or is
planned to use
docker's "ARG and "--build-arg" to pass branch while building?
In the basic form I would see only one dockerfile+image for libosmo* in
master branch that can be used for all osmo-* application build testing.
The given project that you want to build-test would either
a) not be part of that dockerfile/image but simply cloned at 'docker
run' time. Disadvantage: Must be cloned from scratch.
b) a 'git clone' base version of the (or all?) application-under-test
could be part of the Dockerfile/image, so that at 'docker run' time
we simply do a git pull + checkout -f -B of the specific branch we
want to build. Advantage: no need to clone from scratch at every
build, only the delta between 'when image was built last' and the
branch/patch-under-test needs to be fetched from the git server
for 'b' all git repos could be cloned into the base Dockerfile/image,
or we could have one program-specific Dockerfile/image. In the context
of simplicity, I would try to reduce the different number of
Dockerfiles/images, and simply have "all-in-one". The age of those
"program under test" clones doesn't matter (so no "ADD
http://cgit...")uot;),
as opposed to the age of the build dependencies, which must be ensured.
Furthermore, the nightly package of libosmocore-dev
confuses me,
especially when thinking about gerrit jobs. How often are these
packages updated?
The current Dockerfiles in docker-playground.git are built for executing
test software. They re not meant for build testing, please don't
confuse those two.
Afaiu images will be rebuild if a new patch is
introduced. But who is
invoking the rebuild when the parent or libosmocore-dev in the example
have changed?
image[s] will only need to be rebuilt when a patch to the build
dependencies is introduced to the master of such a dependency. They
will not be upated by a patch to the project/repo/app-under-test, as
that one is not part of the image.
The rebuild of the 'libosmo*' image is triggered by 'docker build' at
the beginning of e.g. osmo-bsc-gerrit job.
Sharing same layer for "RUN apt-get install
..." command as shown in
osmo-nitb-master and osmo-bts-master Dockerfile could be promising.
I think that's not really relevant to build-testing.
In general I like the "move" towards docker
compared to lxc, which
does not provide something similar to a Dockerfile.
Well, it provides templates. Similar, but of course different (and no
layer cachce, ...)
On the other hand I am skeptic about the whole life
cycle, which imo
needs some external management as described to keep everything up to
date.
no, fully automatic.
Additionally, every "docker run ..." command
would need a
"docker pull ..." before to ensure latest image from repository.
If you do a 'docker build' ahead of every 'docker run', I don't see
that
need.
I will definitely setup some build jobs on my Jenkins
with those
Docker images to get a better understanding.
Please don't use the Dockerfiles in docker-playground.git. As
indicated, they are built for a completely different purpose and hence
work differently.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)