We anticipate creating short-lived dev branches for new features being developed. Enabling the dev branch builds and publishing the tar.gz/zip results to blob storage is easy, but getting Docker images created/published requires more infra.

I think two approaches generally make sense for different situations, so it would make sense to implement both:

1. When we build a dev branch, have auto-update infra submit the PR into the nightly (Add "nightly" Dockerfiles #169) branch, with a repo/tag suffix that matches (perhaps roughly) the dev branch name. We would have a new set of Dockerfiles for the dev branch, just like adding a new 1.16/1.17/... folder.

   This keeps the Docker repo relatively simple. We won't branch for each of 1.16/1.17/..., so why branch for a dev branch's builds?

2. Create a new dev branch in the go-docker repo. Otherwise the same as (1).

   This is useful if we need to make big changes in the Dockerfiles or even the go-docker infra itself to support the new dev builds. We would want to work on those changes in a separate branch to avoid destabilizing unrelated nightly images. For example, if we need to modify the environment to e.g. add OpenSSL to our images, this would probably be a good case for a go-docker dev branch.