dockerfiles

Dockerfiles and build scripts for the dzangolab Docker Hub organization.

Each subdirectory is a separate image, with its own Dockerfile and README.md. The README.md doubles as the image's Docker Hub description.

Contributing

Building and pushing an image

./build.sh <image> <tag>

where <image> must the name of the image's folder.

This builds a multi-arch (linux/amd64,linux/arm64) image and pushes it to dzangolab/<image>:<tag>. For images that build the two architectures from separate Dockerfiles and join them with a manifest, use:

./build-manifest.sh <image> <tag>

Both scripts automatically sync the image's Docker Hub description (see below) from <image>/README.md after pushing.

Updating the Docker Hub description without rebuilding

If you only changed an image's README.md and want to refresh its Docker Hub description without doing a full build/push, run:

./update-dockerhub-description.sh <image>

This pushes <image>/README.md as the full_description for dzangolab/<image> on Docker Hub.

Credentials

The script needs DOCKERHUB_USERNAME (your personal Docker Hub username — not your email, and not the dzangolab org name) and DOCKERHUB_TOKEN (a Docker Hub access token, not your password) set in the environment. These are stored in .env at the repo root and loaded automatically via direnv — run direnv allow once after cloning.

CI

Each image has its own independent versioning, so a build is never triggered by a plain commit to main — only by pushing a tag.

Tagging convention

Tags are namespaced per image: <image>/<semver>, e.g. mysql-backup-s3/1.2.0. The image name is the name of the directory at the repo root; the version is that image's own version, independent of every other image's.

git tag mysql-backup-s3/1.2.0
git push origin mysql-backup-s3/1.2.0

Pushing this tag triggers .github/workflows/build.yml, which parses the tag, builds only that image (via build-manifest.sh if <image>/Dockerfile.amd64 exists, otherwise build.sh), and pushes dzangolab/<image>:1.2.0 plus its Docker Hub description.

The workflow needs DOCKERHUB_USERNAME and DOCKERHUB_TOKEN configured as repository secrets (Settings → Secrets and variables → Actions).

Pinning the docker-secrets version

Every image that depends on dzangolab/docker-secrets declares it via a Dockerfile ARG DOCKER_SECRETS_VERSION=<pinned version>, defaulting to whatever version that image currently builds against. Pins are independent per image — bumping one image's default doesn't affect the others.

To override the version for a single local build, without editing any Dockerfile:

DOCKER_SECRETS_VERSION=1.1.2 ./build.sh mysql-backup-s3 1.3.0

In CI, the build step picks up the repository variable DOCKER_SECRETS_VERSION (Settings → Secrets and variables → Actions → Variables) if it's set, and passes it as the same build arg — letting you bump every image to a given docker-secrets version on the next tag push, while leaving the variable unset still respects each Dockerfile's own pinned default.