Code reloading for ./pants run src/docker/hw/Dockerfile through mounts

[ptrhck]

Is your feature request related to a problem? Please describe.
Here pantsbuild/example-docker#6 it was discussed that the current implementation of running a Docker container with pants and restartable=True does not feature a great developer experience for developing/debugging purposes as it will rebuild the container on every code change.

Describe the solution you'd like
I am not sure if there are use cases for the current setup that are not covered by the following solution, so I am not certain if the current implementation should be replaced or extended. I would like ./pants run src/docker/hw/Dockerfile to do:

• Build the image if not yet available
• Mount the build artifact, e.g. PEX-file to the container
• On file change, rebuild that artifact and due to the container mount it will be available in that environment without recreating the container or rebuilding the image
• If you have changed the Dockerfile, a --build flag could be added to the ./pants run command, similiar to docker-compose up --build serviceA
• Or if you do not wish to re-use that container set --force-recreate

So basically re-use the container.

Describe alternatives you've considered
To a certain extend, i.e. user code but not third party/user dependencies, it is possible for the AWS Lambda case as here the PEX will be unzipped: ./pants run --docker-run-args="-v ./lambda_example.py:/app/lambda_example.py" project:my_image

Additional context
The same would be benefical for running tests in a container (#13682) as you would not want the container to be rebuild for eacht test run.

[kaos]

@stuhood for this, I'm considering we could add a runtime_dependencies field to docker_image for stuff we want to volume mount into the container when we run the image.
The question is how to wire up restartable so that we rebuild those runtime dependencies, but doesn't actually restart the container, on changes to the runtime dependencies sources. Or is --loop more suitable in this scenario? Thoughts?

[stuhood]

Having a long-lived docker process which stayed up through multiple iterations would require some mutable state passed into the engine invokes, most likely (and then torn down at the end). In that regard, --loop would probably make more sense, because there is actually already a loop running in that case (which could manage some state, and then tear it down at the end).

It's possible that a cleaner implementation though would be to add native docker support to Pants (via a rust side CommandRunner), and then let that runner manage pooling processes. It would be similar to the way that the nailgun CommandRunner pools processes. That relates to #13682.

[kaos]

Makes sense, thanks.
Is the CommandRunner the proper way in to have generic docker support for executing in docker in a similar manner as for remote execution?

[stuhood]

That's right.

[ptrhck]

Just adding another thought to this discussion. I have another usecase that goes a little further. I am not using pants to run that container, but use it for building/publishing the image and then deploy it to localstack. Now I would like to specify to hot reload the pants artifact in the container that is now run by localstack.