Re: [atomic-devel] 3 kinds of "docker build"

[Colin Walters <walters verbum org>]

One thing I find strange about STI myself is that the unit of
interaction is the Docker image, and the source code is an external
thing you supply. 

To me, Docker images are *caches* of source code built in a specific
configuration.  Source code is git repositories, pinned to specific
revisions.

I think source code (+ build configuration) should be the focus, or unit
of interaction.  Most packaging systems I've seen are also wrong in this
- they has an obsessive focus on the metadata, the actual source code is
just a Source0: line, squirrelled away in the lookaside cache or
similar.

While I understand the rationale behind STI's focus on the
build-one-thing, a case I was hitting is this:

I have two Docker images (apps I'm working on), with a common set of
packages shared between them, both deriving from a well-known framework
(base image).  The common set here might include say a configuration or
utility library I wrote.  If I'm working on one of my apps and fix
something in the utility library, I want to potentially rebuild/retest
both images.

Here's a real-world example:
https://github.com/stackforge/kolla/blob/master/docker/fedora-rdo-base/Dockerfile

Now that Docker file is just an *assembly*, whereas I as an app author
will want to build from source.  Say the author of Glance also needs to
update "python-jsonpatch" (to pick a random example).  Clearly in the
glance Dockerfile they could test this by just doing a yum install of
their custom RPM, but I think a more intelligent build system would be
capable of building the python-jsonpatch from *source*, in addition to
taking a custom RPM.

I think this is a quite reasonable real-world scenario that also
highlights the full complexity of the kind of build system I think we
need.  The system could build python-jsonpatch as a standalone RPM, then
be capable of efficiently injecting that updated RPM into derived
images.