New "fig.yml" key: 'run' ?

[mcbhenwood]

It would be great to have an ability to specify Dockerfile-like "RUN" steps, just for the Fig container. My specific situation is this:
My Dockerfile for my Django-based service installs basic service dependencies. However in my Fig container where I run tests and also run the dev server, I would want also to install test dependencies, which should never be built into the Docker container itself, rather as a layer on top for the Fig user.

I have tried a few shell-based ways of doing this but they are all dirty. The beauty of Fig is the way it applies a "thin override" to Dockerfile settings, in a slightly altered container. It seems to me that being able to RUN commands as well, as part of the Fig build, would be a good addition.

[killercup]

I have a similar use case, as I need to run some setup commands that depend on the environment as well (web/test container using the same image).

[kojiromike]

In other words, something to obviate the need for entrypoints that do setup themselves, e.g. mysql?

[mcbhenwood]

No @kojiromike I mean specifically to have shell commands run as part of the Fig build, but not as part of the Docker build. I think my example is a pretty clear one so I will rephrase it:

Dockerfile

• RUN pip install -r requirements.txt

fig.yml

• RUN pip install -r test_requirements.txt

In the same way that fig allows a kind of "light inheritance / override" wrapper around ports, volumes etc of a Dockerfile, so a similar method of "extending" the base container build with additional RUN statements would be very useful

[SvenDowideit]

This dovetales nicely with my desire to do away with trivial Dockerfiles - like the ones that only contain FROM golang:onbuild

if we could have something like

app:
  build:
    - FROM: golang:onbuild

(or in your case, RUN: somethng)

And then fig makes a intermediary Dockerfile :)

[dnephin]

This is not possible with the current docker remote API. There are plans to extract the build process from the API and do it client side, which would make this support even less likely.

In the end, compose is not really a build tool (#1455).

Since this feature is not possible, and it looks like the docker engine is moving in a different direction, I'm going to close this issue, but as always thank you for the proposal!