Integrate with run mount mechanism to improve feature configuration abilities #450
Description
Description
Similar to #345, this proposal seeks to integrate with the Dockerfile Spec's RUN --mount ability. In this case, I'm proposing additionally exposing the ability to use bind mounts during container build, either fully configurable as in #345, or at minimum just mounting in the whole .devcontainer directory.
Motivation
I'm working on a project to create an Azure IoT device, and part of that includes setting up communication between the code under test and the IoT Hub. For various testing reasons, it can be advantageous to perform all activities locally, cutting out the need for developers to register their computers with the actual Azure hub. This is only possible because the remote hub is an MQTT/AMQP broker, so running a replacement broker in a second container is viable (in my case, Mosquitto).
The problem is that one of the things I want to test with my code is endpoint identity setup with certificate/chains, and for patently obvious reasons don't want to put a certificate into my code repository - I create them during container initialization, currently as a postCreateCommand shell script.
Unfortunately, this is actually too late in the process for the Mosquitto container (which accesses the certificates via a shared volume and fails to start because the certificates aren't created yet), and means that after initial devcontainer build the developer must restart their container. Creating the certificates as a devcontainer-feature would (likely? need to test) create them early enough, but I want to be able to generalize the solution for future projects (and likely make it public), so that means I need a way to configure the certificates/chains that get created (for example, by specifying an openssl.conf). And while stuffing entire file contents into a string variable is possible, it's not very user-friendly....
Proposed Solution
At minimum, either default bind-mounting the .devcontainer directory or providing a toggle to do so would allow end-users to specify additional configuration files for cases like this. Allowing features to be able to specify a build bind mount is also possible, but somewhat less interesting...
{
"build": {
"mounts": [
{"type": "bind", "id": "devcontainer", "source": "${localWorkspaceFolder}", "target": "/some/path", "readonly": "true" }
]
}
}