Allow an extended syntax for environment args

Cargo.toml

@@ -11,7 +11,7 @@ license = "MIT"
 name = "dock"
 readme = "README.md"
 repository = "https://github.com/ezanmoto/dock"
-version = "0.32.0"
+version = "0.33.0"
 edition = "2021"
 
 [dependencies]

README.md

@@ -92,7 +92,8 @@ environments:
  build: {}
 ```
 
-Running `dock run-in build make` will do the following, in order:
+Running `dock run-in build make` or `dock run-in build-env: make` (see "Extended
+environment flag", below) will do the following, in order:
 
 1. Rebuilds the Docker image `ezanmoto/dock.build` from a local
  `build.Dockerfile`, if it needs to be rebuilt.
@@ -246,6 +247,36 @@ default:
 * `--init`: This "ensures the usual responsibilities of an init system, such as
  reaping zombie processes, are performed inside the created container."
 
+#### Extended environment flag
+
+`dock run-in` allows providing the name of the environment with an `-env:`
+suffix. This is somewhat unconventional and may be considered inconsistent with
+the established conventions for the layout of UNIX commands and their arguments.
+Furthermore, it goes against the Pythonic principle that is adopted by many
+developers of having "one way to do it." While all of this is true, the
+practicality of the approach is that it may improve the readability of `dock`
+usage in scripts. Consider the following:
+
+ dock run-in build cargo build
+ dock run-in test.build sh -c 'npm i && npm run build'
+
+While this on its own may not be considered too unreadable, the readability may
+be improved with the `-env:` suffix, which highlights `test.build` as the name
+of an environment, and delineates between the "context" of the command (the part
+before the `:`), and the command to be run in the containerised environment:
+
+ dock run-in build-env: cargo build
+ dock run-in test.build-env: sh -c 'npm i && npm run build'
+
+Note that other approaches, like the use of line splitting in shell scripts, may
+be used to achieve equivalent results using more conventional means:
+
+ dock run-in build \
+  cargo build
+
+ dock run-in test.build \
+  sh -c 'npm i && npm run build'
+
 ### `dock shell`
 
 `dock shell` has the same behaviour as `dock run-in`, but instead of running a
@@ -276,8 +307,8 @@ environment by running the following:
 
 ### Building
 
-The project can be built locally using `cargo build --locked`, or can be built using
-Docker by running the following:
+The project can be built locally using `cargo build --locked`, or can be built
+using Docker by running the following:
 
  bash scripts/with_build_env.sh cargo build --locked
 

src/main.rs

@@ -241,6 +241,12 @@ fn handle_run_in(
  if let Some(args) = arg_matches {
  env_name = args.value_of(ENV_FLAG);
 
+ if let Some(env) = env_name {
+ if let Some(e) = env.strip_suffix("-env:") {
+ env_name = Some(e);
+ }
+ }
+
  if args.is_present(DEBUG_FLAG) {
  debug = true;
  }

tests/cli/run_in/success.rs

@@ -129,7 +129,6 @@ fn run_in_returns_correct_exit_code() {
  dockerfile_steps: "",
  fs: &hashmap!{},
  });
- // (2)
  docker::assert_remove_image(&test.image_tagged_name);
 
  let cmd_result =
@@ -1339,3 +1338,30 @@ fn run_in_with_skip_rebuild_doesnt_rebuild() {
  // (C)
  .stdout("a");
 }
+
+#[test]
+// Given (1) the dock file defines an empty environment called `<env>`
+// When `run-in <env>-env: echo hi` is run
+// Then (A) the command returns an exit code of 0
+// AND (B) the command STDERR is empty
+// AND (C) the command STDOUT contains 'hi'
+fn run_in_with_extended_env_flag() {
+ let test_name = "run_in_with_extended_env_flag";
+ // (1)
+ let test = test_setup::assert_apply_with_empty_dock_yaml(&Definition{
+ name: test_name,
+ dockerfile_steps: "",
+ fs: &hashmap!{},
+ });
+ let env_arg = &format!("{}-env:", test_name);
+
+ let cmd_result = run_test_cmd(&test.dir, &[env_arg, "echo", "hi"]);
+
+ cmd_result
+ // (A)
+ .code(0)
+ // (B)
+ .stderr("")
+ // (C)
+ .stdout("hi\n");
+}