cgerling / dockeryard

A personal Docker registry based on GitHub Packages

dockeryard

A personal Docker registry based on GitHub Packages.

dockeryard's Issues

Explain image lifecycle

Split Into Multiple Repositories

We could reuse more logic if we moved some stuff out of this repository, leaving just Docker-related files.

Multi Arch Support

This is already supported by Docker by creating multiple tags for each arch.
I prefer to wait for the buildx command to become stable and then add this feature here.

Dedicated build status

Show somehow the individual build status of each image

Auto tag as latest

Dedicated workflows

Nowadays there's a single workflow to handle all custom images, because of that every update on any image triggers a "publish"* for all images present on the repository. This is not sensitive since the only thing affected is the delay between the update itself and the image is available to use, a cache could be configured to fasten the process a bit but it still does unnecessary work.
One possible solution is to create a workflow configuration for each image that triggers only when there's some update on their files together with a custom action that actually publishes* an image to a registry, to reduce the boilerplate necessary to add one.
An ideal solution would be a generic action that dynamically checks which image was updated and publishes it but I don't know how pratic this would be since GitHub Actions doesn't seem to support a lot of dynamic behavior, for obvious reasons.

*with publish I refer to the build and push process

Multiple Tags per Image

In the current state, we have a meta.sh script file to provide metadata about the image but the truth is that we just need a tag name for the image, so it would be better to rely on a more flexible system and reintroduce the meta.sh file concept later when actually needed.

Migrate to GitHub Container Registry

https://docs.github.com/en/free-pro-team@latest/packages/getting-started-with-github-container-registry/about-github-container-registry

Specific workflows

Since the ground was laid on #1 we can focus on minor improvements to achieve a more seamless workflow. Nowadays only changes on the master that affect some image related file (workflow configuration or something inside images/{image}) triggers a workflow that will release a new version on the registry, but this behavior isn't always intended because we need to check if the image changes will work (in this case just build successfully) without releasing this new version to the registry before merging a PR, to avoid pushing unapproved things to the registry.