Consider supporting plugin-specific builders

[alanking]

Instead of using a single plugin builder which calls the build hook script provided by each plugin, we should consider having each plugin provide its own builder Dockerfile which includes all of the required build dependencies. This would make the iteration cycle for developers much faster and avoid wasted downloads (which would occur only when rebuilding the image).

In order to support integration with CI, we should probably also develop a tagging scheme in order to generically build plugins by running the builder images.

As a future enhancement, this may include having the development environment provide a "base image" of sorts for each supported platform to avoid some duplication.

[trel]

I really like the base image/dockerfile idea... but it would live in this repo, while the per-plugin ones would live... 'over there'.

Can per-plugin builder dockerfiles be built upon URL-defined base dockerfiles?

[alanking]

Not sure. I think you can only specify a base image using the FROM command, which would mean the base image would have to already have been built.

[stefan-wolfsheimer]

Thank you for bringing this issue to the agenda. For plugin developers, this mechanism will definitely help to accelerate and simplify the development process. In practice, this implies that most of the dependency definitions would move from the build hook to the Dockerfile, right?

As far as I know, it is indeed only possible to base an image on another image, and not on a URL-based Dockerfile (not sure if there are other mechanisms to include Dockerfiles in Dockerfiles).

Here's my point of view as an external plugin developer:
An easy solution could be to instruct plugin developers to build the base images themselves such they use the locally tagged image in the FROM statement of their own plugin Dockerfile.
This is not too much effort regarding maintaining the base system (no need for hosting a registry) and it is yet approachable for plugin developers and testers.

[alanking]

That's correct, @stefan-wolfsheimer. We would migrate (or duplicate?) the requirements which currently live in the build hook to a Dockerfile which could then be made into a builder image. This would of course require a script similar to the existing "core" builder, and that could be fetched from a URL as part of the image-building process. As long as the plugins are proper CMake projects it should be pretty straightforward to put together a generic way to build all of them (i.e. run cmake, run make, pass options as appropriate).