Skip to content

Instantly share code, notes, and snippets.

@SeanTAllen
Last active August 7, 2019 00:02
Show Gist options
  • Save SeanTAllen/2a03bb991e106c736d63770b4c7680a9 to your computer and use it in GitHub Desktop.
Save SeanTAllen/2a03bb991e106c736d63770b4c7680a9 to your computer and use it in GitHub Desktop.
Proposal to change how we organize Ponylang CI related docker images
# 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`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment