RFC: Add --no-docker option #11
Conversation
This is helpful if we want to build apps in jenkins where it is convenient to install cargo-acap in a docker image and inconvenient to set up docker-in-docker.
|
🤔 If you're intending to run
The net result being that the user can either install If you're intending to use |
|
Sorry for the late reply, I should have predicted that opening a PR right before going on vacation is a bad idea. That does indeed sound like it would address my situation. Re 1; I had not thought of this and it is not critical for my use case since I will always have a Re 2; It is also possible to detect docker automatically but I think your suggestion is better since it let's the user choose explicitly what to do. Compared to using command line options I also like that commands will be the same inside and outside the container, (but I also recognize this could be due to an excessive desire for tidiness 😁). I'll update the PR to incorporate your suggestions. |
I tried to make clap parse this but by default clap will treat any value, including "", "0", and "false" as true. Every way I tried to change this would introduce some other problem. For instance changing the action to set would make it show up as a positional argument. The values accepted are limited to "0" and "1" because this is sufficient to communicate all options, and adding more accepted values is easier than removing them.
This makes it easier for downstream users to use docker in CI without setting up docker-in-docker. These changes can be tested locally by doing something like ```sh cargo install \ --path . \ --root cargo-acap-build pushd cargo-acap-build docker build \ --build-arg RUST_VERSION=1.74.0 \ --tag cargo-acap:1.74.0 \ . popd docker run \ --env CARGO_ACAP_NO_DOCKER=1 \ --interactive \ --rm \ --tty \ --user $(id -u):$(id -g) \ --volume <PATH_TO_SAMPLE_APP>:<PATH_TO_SAMPLE_APP> \ --volume ~/.cargo:/.cargo \ --workdir <PATH_TO_SAMPLE_APP> \ cargo-acap:1.74.0 \ cargo-acap build ```
This is helpful if we want to build apps in Jenkins where it is convenient to install
cargo-acapin a docker image and inconvenient to set up docker-in-docker.Does that make sense?
If so I will clean up the PR.