mix burn cannot be operated from Docker container

[takasehideki]

NOTE:
Although think it is hard to fix this issue due to the restriction of Docker especially for Windows and macOS, we leave this open because this report is useful information for new people. And we believe that technology will evolve well:pray:

It is nature that burning firmware to microSD from Docker container is hard to support.
But it become awesome if mix burn can be operated from docker dev-container.

Please also see NervesJP/nerves-devcontainer#5

[takasehideki]

(Copied from NervesJP/nerves-devcontainer#5 (comment))

Status on macOS

root@be6d80382017:/workspaces/nerves-devcontainer/test# mix burn 
==> nerves
==> test

Nerves environment
  MIX_TARGET:   rpi4
  MIX_ENV:      dev

** (Mix) Could not auto detect your SD card

This is because Docker container cannot access/detect microSD on host PC. One possible solution is calling fwup on host PC from Docker container. Alternatively, binding microSD device to docker container filesystem. But, are they possible?

[takasehideki]

(Copied from NervesJP/nerves-devcontainer#5 (comment))

status on windows:

root@923930b7aad1:/workspaces/nerves-devcontainer/test# mix burn 
==> nerves
==> test

Nerves environment
  MIX_TARGET:   rpi4
  MIX_ENV:      dev

** (ErlangError) Erlang error: :enoent
    (nerves 1.7.0) lib/nerves/port.ex:88: Nerves.Port.validate("cmd.exe", ["/c", "echo %TEMP%"], [])
    (nerves 1.7.0) lib/nerves/port.ex:25: Nerves.Port.do_cmd/4
    (nerves 1.7.0) lib/nerves/utils/wsl.ex:94: Nerves.Utils.WSL.get_temp_file_location/1
    (nerves 1.7.0) lib/nerves/utils/wsl.ex:237: Nerves.Utils.WSL.make_file_accessible/3
    (nerves 1.7.0) lib/mix/tasks/burn.ex:66: Mix.Tasks.Burn.run/1
    (mix 1.11.2) lib/mix/task.ex:394: Mix.Task.run_task/3
    (mix 1.11.2) lib/mix/cli.ex:84: Mix.CLI.run_task/2

This is because current Nerves supports (native) WSL2 environment for Windows users. We may modify Nerves environment to resolve this situation.
The way to detect whether a container is based on WSL2 or native docker is uname -r and ls /.dockerenv
Ref: https://github.com/ETrobocon/etrobo/blob/master/scripts/etroboenv.sh#L55

[takasehideki]

@jasonmj suggested the useful information on ElixirForum.
https://elixirforum.com/t/nerves-development-environment-with-docker-and-vs-code/35973/3

When the host is Linux, I've surely checked this method works well.
However, I've also found it is not possible to pass through a USB device (or a serial port) to a container as it requires support at the hypervisor level both in Windows and macOS as the host.

I've added these info to README at 0a0262d

[takasehideki]

I also found an alternative way to use docker-machine and VirtualBox to pass through devices.
https://christopherjmcclellan.wordpress.com/2019/04/21/using-usb-with-docker-for-mac/

However, this operation is complicated and unacceptable as a guide for beginners.

[takasehideki]

(Copied from NervesJP/nerves-devcontainer#5 (comment))

status on windows:

root@923930b7aad1:/workspaces/nerves-devcontainer/test# mix burn 
==> nerves
==> test

Nerves environment
  MIX_TARGET:   rpi4
  MIX_ENV:      dev

** (ErlangError) Erlang error: :enoent
    (nerves 1.7.0) lib/nerves/port.ex:88: Nerves.Port.validate("cmd.exe", ["/c", "echo %TEMP%"], [])
    (nerves 1.7.0) lib/nerves/port.ex:25: Nerves.Port.do_cmd/4
    (nerves 1.7.0) lib/nerves/utils/wsl.ex:94: Nerves.Utils.WSL.get_temp_file_location/1
    (nerves 1.7.0) lib/nerves/utils/wsl.ex:237: Nerves.Utils.WSL.make_file_accessible/3
    (nerves 1.7.0) lib/mix/tasks/burn.ex:66: Mix.Tasks.Burn.run/1
    (mix 1.11.2) lib/mix/task.ex:394: Mix.Task.run_task/3
    (mix 1.11.2) lib/mix/cli.ex:84: Mix.CLI.run_task/2

This is because current Nerves supports (native) WSL2 environment for Windows users. We may modify Nerves environment to resolve this situation.
The way to detect whether a container is based on WSL2 or native docker is uname -r and ls /.dockerenv
Ref: https://github.com/ETrobocon/etrobo/blob/master/scripts/etroboenv.sh#L55

This has been fixed at #2
The situation on Windows is now same as on macOS.