Docker build automation
Overview
This package provides a script which builds multiple Docker containers in sequence, using the contents of a docker_images.txt file in some directory. This file is tab-delimited, and lines starting with # are ignored.
Each non-comment line in docker_images.txt is of the format:
label path/to/Dockerfile comma,separated,options,if,desired
(with arbitrary whitespace between pieces). By default, images will be built by running docker build -t label -f Dockerfile . in the parent directory of the Dockerfile. Add the option base_directory_build after the Dockerfile to specify that the image should be built with:
docker build -t label -f path/to/Dockerfile .
in the directory containing docker_images.txt instead. If the default behavior is acceptable, the third tab-delimited piece of each line can be omitted.
Docker images will be built in sequence, so images can refer to the results of previous images, e.g.:
image-base base/Dockerfile image-dev dev/Dockerfile
with dev/Dockerfile containing:
FROM image-base ...
Since images are unconditionally built with the latest tag, first, then tagged with a timestamp if desired, no Dockerfile needs to be modified for a “release” image.
The container build script checks for any uninitialized Git submodules, and by default refuses to build if any are found. This can be overridden if desired (see below).
The build option write_git_version accepts a file path argument, to which the output of git describe --dirty --always --abbrev=12 is written. For example:
image_label path/to/Dockerfile write_git_version=src/revision.txt
Cross-platform builds
The build option platforms accepts a &-delimited list of platforms, which will be passed directly to docker build --platforms=..., with & replaced by , in the docker build invocation. Note that this may require usage of the newer buildx tool, replacing the legacy docker build.
Usage
The command-line entry point provided by this script is build_docker_images. By default, images will be tagged with :latest appended to the base image name.
Options:
- --tag-timestamp
In addition to tagging images as latest, also tag with a timestamp in YYYYMMDD-HHmmss format. All images in docker_images.txt are tagged with the same timestamp. Can be combined with --tag=tag_name.
- --tag=tag_name
In addition to tagging images as latest, also tag with the tag name provided. All images in docker_images.txt are tagged with the same tag name. Can be combined with --tag-timestamp.
- --push
Push all built containers to Docker Hub, tagged as latest and with any additional tags specified via --tag-timestamp or --tag=tag_name.
- --ignore-missing-submodules
Allow building Docker containers if git submodule reports that at least one submodule is uninitialized.
- --pretend
Run in pretend mode: don’t actually execute anything (building, tagging, pushing).
Requirements
Python 3.6 or newer for this script. Docker to build/tag/push images (version unimportant).
Metadata
Release files for multi-docker-build 0.7.3
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| multi_docker_build-0.7.3-py3-none-any.whl | Python 3 | none | any | Details |
Release files / multi_docker_build-0.7.3-py3-none-any.whl
| Download URL | multi_docker_build-0.7.3-py3-none-any.whl |
|---|---|
| Size | 8.1 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
0da124524798d0f25dc45e1e51ccebb1d1cee48dc105e8665b5ef052aa542c17
|
|
BLAKE2b-256 checksum How to use checksums |
478db9fa65494d71b184f6b6ad8539fd5d2e95a1784ff26ab57ff3887bee9085
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/6.1.0 CPython/3.12.2
|
Security for multi-docker-build 0.7.3
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.