@djmaze this also came up in a recent thread https://discuss.drone.io/t/approach-for-browser-integration-testing/47/2
since this comes up frequently, I'm going to give a pretty lengthy response with some background information
Drone is currently optimized for compiling code and running tests first, and then building your image as an artifact. Drone is not currently optimized for building your image first, and running tests inside the image. So why is this the case?
This stems from the fact that my background is in compiled languages. If you look at any docker images for my projects (including
drone/drone) you will notice we compile our binary outside of Docker and then
ADD it to our image. This allows us to add the raw binary to our image without including the Go runtime, source code, or dependencies. This is the difference between a 20mb image and a 700mb image.
While this works great for compiled languages, and works for dynamic languages, it is certainly less optimal for dynamic languages. I know myself (and especially @gtaylor and others) would like to see a workflow that is optimized for dynamic languages as well.
The proposal you've laid out certainly seems like the right way to go about it. I'll add some minor comments.
The way I see it, the best way would be to supply a "docker" build step which builds an image and allows to run tests on it.
Makes sense. It might be a bit tricky adding this to the build section given Go's static typing. If that ends up being the case we could add a new top-level
docker section to the yaml. Either way, this wont' be a showstopper.
For each of the commands given, it runs a new container from the image, with the command given as run parameters.
We expose a
command section in the yaml that corresponds to
docker run [command] which I would suggest we use initially. I'm not opposed to the idea of multiple commands but there are some complexities, such as parsing the command string into a
string which is required by the docker remote api.
We could also allow overriding the Docker ENTRYPOINT
We already expose the
entrypoint in the yaml structure so we won't need to do anything special to enable this.
Am I missing something for this to work?
This proposal seems to include everything at a high level.
I think some low level design details, such as how we build, run and compose will need to be worked out. On the surface these probably don't seem like a big deal, but the implementation isn't going to be as straightforward as you'd expect. I don't have time to get into the full details right now, but we can discuss these finer points in the coming weeks.