`cage up --init` to simplify first-time startup

[emk]

Right now, to start a project for the first time, we need to run something like:

cage up db
cage run rake db:create
cage run rake db:migrate
cage up

The exact series of steps varies, and internally, we wrap cage in shell scripts so we don't get confused by which steps to take when. But it would be really nice to be able to call:

cage up --init

...and have cage do all that other stuff for us.

How it could work

This could be accomplished by creating config/hooks/init.d/10_db_init.hook and filling it with:

#!/bin/bash

set -euo pipefail
case $POD of
    db)
        cage run rake db:create
        cage run rake db:migrate
        ;;
    *)
        # Do nothing
esac

The sneaky bit is that if we write:

cage --target=test up --init

...then the --target=test option should be trivially available to cage inside the hook script, perhaps using an environment variable (to minimize the amount of magic):

cage $CAGE_OPTS run rake db:create
cage $CAGE_OPTS run rake db:migrate

Implementation tasks

Update: We have a new design in the thread below! These implementation tasks assume that design.

• [x] Add run_on_init to *.metadata.yml
• [x] Refactor CommandCompose
• [x] Add --init argument to up and implement.
• [x] Get running container information from Docker.
• [x] Poll for open port on container (see https://github.com/notkild/port_scanner-rs/issues/1).

[emk]

OK, having seen the speed with cage is being ported to Windows, and looking at the predictable nature of our sample hook script, I've decided to go for a radically different design that doesn't require any shell scripts for initialization.

Instead, our sample db.metadada.yml will contain:

# A list of commands to run automatically when `cage up --init` is called
# on this pod.  These behave as though passed to `cage run`, so the first
# argument must be the name of a pod or a service.
run_on_init:
- ["rake", "db:create"]
- ["rake", "db:migrate"]

The arguments to run_on_init are a series of arguments to pass to cage run internally, because—for maximum portability—you really ought to just containerize all your initialization anyway.

But this will almost certainly require us to detect and poll container ports to see when they become available. More on this soon.

[emk]

Shipped in 0.1.8.