Closed georgik closed 3 years ago
@rgcottrell @JurajSadel @mabezdev @igrr @jessebraham @ivmarkov Please review the change.
I'm not really knowledgable in this stuff as I've yet to use these docker images... so take this with a grain of salt, but... my understanding was, that we need Docker images for the tooling only. Meaning: the Rust compiler, clang, Espressif toolchains, whatever else necessary for the "cmake-first" example, and whatever necessary for the "cargo-first" example.
Why are we pushing the example projects themselves inside the docker images?
Why are we pushing the example projects themselves inside the docker images?
The advantage here is that we are showing an example of how to build off of the tools-only docker image to add additional project-specific tooling and environmental setup that could serve as the basis of local developer builds or CI jobs. I agree, however, that checking out the project again might be a bit weird.
Another option would be to mount the root of the repo as the image's working directory. That would allow changes and build artefacts to be more easily shared between the host and the image.
Another option would be to mount the root of the repo as the image's working directory. That would allow changes and build artefacts to be more easily shared between the host and the image.
That would be my preference as well, as this makes moving on from "running the example" stage to the "developing your project" stage more natural. It might be as simple as having a list of steps on "how to build this example using Docker" which includes cloning or downloading this repo.
Great discussion. I see that more explanation should be included and that developer workflow with Docker might not be obvious.
Docker is really great for having a stable reference environment. Something like a "snapshot" of working state. Dockerfile provides a way how to describe the environment in repeatable fashion.
Some IDEs like Visual Studio Code provides even plugins which allows work in the container to look-like local work.
The major advantage for developer is quick and clean bootstrap. The developer can then discard the environment quickly and cleanly. It's even possible to make a snapshot of the environment and ship it to other machine using docker commit
and docker save
.
Bootstrapping process to have working environment with ESP-IDF + Rust is just one command:
docker run -it espressif/idf-rust-examples
E.g. I was trying to configure environment for std example for an hour on macOS and still something was wrong. I was not able to build a component, because something was not correct. With the Docker I was able to build the example within few minutes. Then it was necessary just to copy result from the container and flash it:
docker cp CONTAINER_ID:/opt/rust-esp32-std-hello/target/xtensa-esp32-espidf/release/rust-esp32-std-hello .
Closes https://github.com/ivmarkov/rust-esp32-std-hello/pull/8
The idea behind this PR is to have two images:
Right now we have two examples: