Proposal to change how we organize Ponylang CI related docker images

gistfile1.txt

# CI image overview problem

This is based on a number of problems I've seen with the adhoc system we've developed.

In general right now, everthing is of the form: 

- ponylang/ponyc-ci:shellcheck. 

The is problematic when we need to make breaking changes to an image, for example to remove SSL. 
When I did that, once the images were updated, all existing jobs for one PRs etc would break. I 
consider this a large flaw in how we approach this.

Further, since we started, we are now having images that are for repos other than ponyc. It will 
go hard to know where to go to find the Dockerfiles needed to update as we have more and more repos.

I propose we do the following:

## Where Dockerfiles live

### Dockerfiles specific to CI takes for a given repository live in a `.ci-dockerfiles` directory in 
that that repository. 

By living in the same repo where the generated images are used, we can version the changes to the 
Dockerfiles along with corresponding changes to CI configuration

### Dockerfiles that are shared across different repositories live in a repo called `shared-docker`

Once we need to use a Docker image across repositories, we have 2 choices. We can not share that image 
and have 1 per repo, for example, each repo could have an version its own `shellcheck` image. This in 
the end, seems like a waste and likely to be broken as people copy and paste things. Instead we have a 
repo called `shared-docker` that is for all Dockerfiles for images that we use across repos.

## Image naming

All CI images will be named in the following way:

ponylang/REPO-ci-INFORMATIONAL:YYYYMMDD

for example, a ponyc llvm 7 images created on July 2nd, 2019 would have the name:

- `ponylang/ponyc-ci-llvm-7:20190702`

and a shellcheck image that is shared across repos and was generated on January 1, 2018 would have the name:

- `ponylang/shared-docker-ci-shellcheck:20180101`

### Why use a date as the tag?

By using a date as a tag, we can avoid breakage when we do an update. This does mean that can't push a 
change that updates all images in use for CI without also updating the corresponding CI configs. I consider 
this to be a pro, not a con. It's extra work when updating but removes the "spooky action at a distance" that 
we currently have.

### Image naming for dependent build Docker images

We have some docker images that we want to keep up to date with the latest comings and going of other packages.
That is, we have images that we always want to be use most recent ponyc or the most recently released ponyc.
The same would apply to stable, corral, etc that might be included in the image.

Our nightly builders are an example of this, we want to use the most recent ponyc for latest and most
recently released ponyc. For these, our tags would be `latest` and `release`.

For example, the ponyup nightly builder with the latest and greatest of everything Pony would be:

- `ponylang/ponyup-ci-nightly-builder:latest`

And ponyup nightly builder that relies on released versions of the Pony tools would be:

- `ponylang/ponyup-ci-nightly-builder:release`