Add actions to build and push images to Docker Hub #73
Conversation
As discussed in ckan/ckan#8143 TODO: Decide when to trigger the builds
|
is it better to reference the latest ckan-X.Y image instead of a specific point release? IIUC the docker registry lets us update these links, users can get the latest by building and we don't need to update the tags inside the repo on every ckan-docker-base release. |
|
Maybe once a new release has been pushed to DockerHub ie: |
It's not clear we are using this, and they were installing a system-wide packaging package that could not be uninstalled when installing CKAN requirements: error: uninstall-distutils-installed-package Cannot uninstall packaging 21.3 ╰─> It is a distutils installed project and thus we cannot accurately...
… into build-push-actions
Three main focuses: * Consolidate version handling. We had version numbers all over the place and many different variables with slightly different meanings. Now we only have the version defined in one place (VERSION.txt), and the vars have been consolidated (Dockerfiles only use CKAN_REF, and the ones in the shell script should be hopefully named as what they are) * Centralize building (and pushing). Rather than 8 different Makefiles mostly identical we now only have one bash script at the root of the file which builds the relevant images according to the passed parameters, e.g.: ``` ./ckan-docker-base.sh build 2.11 ./ckan-docker-base.sh build master ./ckan-docker-base.sh build 2.10 base ./ckan-docker-base.sh build 2.0 dev ``` It also centralizes commands for pushing the images to DockerHub, but that will be soon done via GitHub Actions so it's discouraged. * Reduce number of Dockerfiles. While we still keep separate images for prod and dev environments, they are all now built from the same Dockerfile using staged builds and the Buildkit ability to just build the stages needed to build the final image (so buildkit must be enabled with `DOCKER_BUILDKIT=1` when running `docker build`)
According to the docs [1], `released` means that: > A release was published, or a pre-release was changed to a release Seems like a good event to trigger it, as we can create drafts without publishing the images [1] https://docs.github.com/en/webhooks/webhook-events-and-payloads#release
|
@kowh-ai @wardi This is now ready for review. The latest changes to simplify the repo made this much easier and the workflows are pretty minimal and shouldn't require updates (e.g. version numbers) going forward. Right now publishing will be triggered when a new release is "released". According to the docs this means that:
Seems like a good event to trigger it, as we can create drafts without publishing the images yet |
As discussed in ckan/ckan#8143, we want to automate the publication of artifacts as much as possible, in this case the building and pushing of CKAN Docker images to Docker hub.
This PR adds a new reusable workflow that is call for each CKAN version to build.
The actions work but there's stuff we need to decide before merging.