purpose

Consistency between running containers for build and deploy and possibly other scenarios in the future.

problem

We need consistency between the docker run for build and docker run for deploy, but in future other scenarios may also present itself. With the addition of dokku-args we can now mount volumes, for example, but this is currently only implemented for deploy which is problematic for the build process which is now unaware of these volumes.

Another inconsistency which already revealed itself as well, as pointed out by #511, is the absence of a CONTAINER lookup which is only created at deploy and never populated when a build fails or is terminated.

proposal

To avoid duplication and improve reusability a function wrapping the common functionality can be employed, as this merge request would suggest. To reduce cognitive friction in implementation, a compatibility with the original docker implemented call signature was sought hence the function name docker_run.

 $ docker_run [[call arguments] [..]] <docker image> <command> [[command arguments] [...]]

The method will dynamically parse arguments to deduce that everything before the global variable $IMAGE is considered call arguments and everything post this reference will be part and purpose of the command. This allows executing of the function docker_run in exactly the same familiar fashion as we would otherwise call docker run for this purpose with no concern for dokku-args, which gets injected before the image, or any future evolutions of the way a container is run.

This was also the most logical instance at which to log the container id while effectively obfuscating the complexities/requirement from the caller which continues to receive the output as it normally would.

possibilities

Currently only applicable to and implemented for build and deploy but may in future apply to other scenarios as well.

Another consideration would be to enhance the hook api and to separate the arguments passable to build and deploy etc. which should not obstruct this merge request nor be reason to complicate the calling signature as is proposed.

Due to the fixed nature of the process flow identifying which process is calling can be facilitated by a simple counter persisted externally or based on other artifacts created in the $APP location. We could choose to simply pass this identifier along to a new dokku-args hook specification or create separate hooks for each all without additional requirements to the caller.