mattrasband/buildr

Experimental CI System, built around docker containers specific to stages

buildr's Issues

testing

Real projects test themselves, get on it.

Encrypted environmental variable

Versioning the deployment loses some value if we can't include the envvars required with the build. It could be a good feature to include an encrypt option in which the build agent knows the key but nothing else does.

Enable `only` filtering

Enable ability to conditionally run a stage, or skip otherwise.

Image isn't pulled automatically

If the image is not already on the host system, it is not automatically pulled resulting in a 404 Client Error

Per-Stage Container

Evaluate the feasibility of using a container per stage and the relative benefits of whether or not that really makes sense. (ATM leaning toward no for v1.0.0 given that the docker.sock is mounted and the user could do a single command in a container, not sure it makes sense to do a group).

Nested container volume mounting

If you run buildr in a container with the host's docker.sock mounted, it is controlling sibling containers. Effectively this means that volume mounts are from the host system (not the buildr container) - so trying to mount the project dir from inside the docker container in the sibling doesn't work.

We need to enable a way to use the correct volume, depending on the environment. This could either be sharing a volume, or knowing where on the host the mount is from.