Build a watch_edition docker image?

[raytung]

No description provided.

[adamhope]

We've tried docker before, seemed to be a reasonable amount of messing around for little gain...

[watsonarw]

Perhaps another option here: Instead of building a docker image, we use one of the base node images, and mount the current working directory as a volume. Then we execute any node/npm commands (hidden in the ./go script), within the image which provides the node and npm executables. By doing this, we shift the hard dependency from a specific version of node installed with nvm/brew/windows installer, to Docker (via Docker for Windows and Docker for Mac).

I've just quickly hacked together a thing. Your dev-environment script would look something like

#!/bin/bash -eu

NODE_VERSION=8

docker run \
  -it \
  --rm \
  -p "8000:8000" \
  -w "/app" \
  -v $(pwd):/app \
  "node:${NODE_VERSION}" \
  "${@-bash}"

And in your ./go script you'd have something like

if [[ $1 == "install" ]]; then
  ./dev-environment npm install
fi

if [[ $1 == "test" ]]; then
  ./dev-environment npm  test
  exit $?
fi

# ...

Or if you really want, you can put the dev-environment stuff as a function in ./go

[raytung]

That's the approach I would go with too. As a bonus, the latest Node image comes with yarn.

[watsonarw]

There were some comments on #3 about docker, which I'm copying over here.

We run everything through Docker so we don't have to worry about nvm, yarn, or npm or whatever else 😄
@raytung

Do we really expect the students to have/setup docker?
@aaron-m-edwards

I commented in another thread, Docker seemed like more hassle than it was worth last time we tried it.
@adamhope

[watsonarw]

My thoughts are:

1. Regardless of whether we go with docker or not, we're going to have a hard dependency that we can't install easily.
   a) With Docker, it's Docker via Docker for Windows or Docker for Mac
   b) Without Docker, it's Node, via a platform specific node installer, or homebrew for mac, or nvm/nodenv (possibly via homebrew).
2. Docker for Windows and Docker for Mac make Docker much easier than it was in the past
3. Docker means that things like node versions are much easier to keep consistent, and we're less likely to have platform dependent issues. It also means that the only difference in the setup/running instructions between Windows and Mac is which "Docker for ___" installer you run.
4. If we're hiding the actual commands behind a ./go script, then the ugliness of running things in docker is hidden away from students.
5. If CI runs in a docker image, then everything is running in the same environment.

I'm personally leaning towards running everything in a docker image...

[aaron-m-edwards]

If CI runs in a docker image, then everything is running in the same environment.

Circle provides it's own docker images, I don't know if we can actually docker pull/run those images

[watsonarw]

If we can run the commands inside a standard docker image (e.g. node:8), then we should be ok, but setup might look strange. From what I can tell TravisCI can run build jobs with docker

[adamhope]

I have a feeling last time we used Docker some of the Windows based students had issues getting it installed and working correctly. If we can be reasonably confident that Docker is easy to install on a range of Windows laptops AND is hidden behind the go script I'm okay with it. In my experience VirtualBox is easier to get working on Windows although it is more of a brute force solution.

I think most students would probably find it a bit easier to resolve VirtualBox issues than ones with Docker.