DOKK / manpages / debian 13 / autopkgtest / autopkgtest-build-docker.1.en
autopkgtest-build-docker(1) General Commands Manual autopkgtest-build-docker(1)

autopkgtest-build-docker, autopkgtest-build-podman - Create or update autopkgtest image for autopkgtest-virt-docker, autopkgtest-virt-podman

autopkgtest-build-docker [options] [-- extra docker-build args...]

autopkgtest-build-podman [options] [-- extra podman-build args...]

autopkgtest-build-docker creates or updates a Docker or Podman image which is suitable for autopkgtest's Docker/Podman runner autopkgtest-virt-docker(1) or autopkgtest-virt-podman(1).

When run as autopkgtest-virt-podman or with the --podman option (recommended), Podman is used for building images. This can be done unprivileged.

When run as autopkgtest-virt-docker or with the --docker option, Docker is used. This requires root-equivalent privileges on the host system. Using Podman instead of Docker is recommended.

The images produced by this tool are intended to be suitable for use with either Podman or Docker.

The image used for testing is built using docker-build(1) or podman-build(1) from a base image or tarball, using a recipe that adds deb-src apt sources, runs apt-get update and installs build dependencies.

If the --tarball option is used, the image used for testing is based on that tarball, and no base image is downloaded.

Otherwise, it is based on a pre-existing base image. The default is to download a suitable base image for the detected or configured OS vendor from a third-party container registry. The --image option can be used to select a different base image.

You can specify an apt proxy to use in the container in the --apt-proxy parameter. If you have an apt proxy configured on the host, the container will automatically use this, otherwise there is no default.

Container image to use as base image. The default is derived from the --vendor and --release by assuming that image names follow the same pattern as the semi-official Debian Docker images (debian:RELEASE) and the official Ubuntu Docker images (ubuntu:RELEASE). If the --tarball option is also used, this option still affects the default --tag but no base image is downloaded. Otherwise, the image will be downloaded from a third-party container registry if required, using the same configuration and aliasing rules that are normally used by docker-pull(1) or podman-pull(1). For both Debian and Ubuntu, this will usually result in downloading docker.io/library/VENDOR:RELEASE from Docker Hub.

Operating system vendor to use. This is used to set defaults for parameters like --image and --mirror. The default is to guess from the --release if specified, or from the --mirror if specified, or use the --image as-is if specified, falling back to Debian if no image is specified.

Operating system release (suite) to use. The default is to guess from the --image if specified, or use unstable for Debian, or use whatever image is tagged as latest for other vendors.

Image name to tag the new image. When using a base image, the default is to prepend autopkgtest/ to the name of the base image, resulting in an image name like autopkgtest/debian:unstable. When using a --tarball, the default is to use a name based on the --vendor and --release (matching the default base image), again resulting in a name like autopkgtest/debian:unstable. If the base image starts with localhost/, that prefix is removed, to reduce repetition when using podman. If the --init option is used, then the init system is also added to the default tag name, resulting in an image name like autopkgtest/systemd/debian:unstable. When using Podman, if no destination registry is specified, local storage will be assumed, resulting in a name like localhost/autopkgtest/debian:unstable.

Add the specified init system to the container image, so that it can be booted as a full-system container using a command like podman run IMAGE /sbin/init or autopkgtest-virt-podman --init IMAGE. By default, whatever init system is in the base image is kept, usually meaning no init system at all (so the container can be used to run individual shell commands, but cannot be booted like a full system and will not provide the isolation-container autopkgtest capability). The presence or absence of an init system is recorded in the image's metadata so that autopkgtest-virt-podman(1) can automatically detect whether to enable or disable --init.

Mirror for apt. The default is http://deb.debian.org/debian/ for Debian, or http://archive.ubuntu.com/ubuntu/ for Ubuntu, or whatever mirror is configured in the base image otherwise.

Proxy for apt. If you have an apt proxy configured on the local host, the image will automatically use this; otherwise there is no default.

Run shell command in the image after the setup.

Import a pre-prepared root filesystem tarball as generated by debootstrap(1), mmdebstrap(1) or a similar tool, and use it as the root filesystem of the container before adding autopkgtest customizations. If this option is used, no base image is downloaded from third-party container registries; the --image is used to choose the default --tag but is is otherwise ignored.
In addition to Essential packages, autopkgtest-virt-docker currently requires at least the apt and passwd packages to be included, so the smallest suitable tarball is the output of mmdebstrap --variant=apt --include=passwd RELEASE. It is more typical to use a --variant=minbase tarball, which is also used as the basis for the docker.io/library/debian:RELEASE images.

You can pass additional options to Docker or Podman: any positional arguments, or any arguments at all after a --, get passed verbatim to docker-build(1) or podman-build(1).

It is recommended that you always use a -- to distinguish these arguments, for readability.

If the $AUTOPKGTEST_KEEP_APT_SOURCES environment variable is set to a non-empty value, autopkgtest-build-docker will keep whatever /etc/apt/sources.list was inherited from the base image.

Otherwise, if the $AUTOPKGTEST_APT_SOURCES_FILE environment variable is set to a non-empty value, for example AUTOPKGTEST_APT_SOURCES_FILE=/home/me/mydistro/sources.list, then autopkgtest-build-docker will read that file (on the host system) and use it to populate /etc/apt/sources.list in the virtual machine; or if the $AUTOPKGTEST_APT_SOURCES environment variable is set to a non-empty value, for example AUTOPKGTEST_APT_SOURCES=$(cat /home/me/mydistro/sources.list), autopkgtest-build-docker will write it directly into /etc/apt/sources.list in the resulting container image.

When $AUTOPKGTEST_APT_SOURCES_FILE or $AUTOPKGTEST_APT_SOURCES contain sources in the deb822 format, then sources are written to /etc/apt/sources.list.d/<distro>.sources in the container, rather than /etc/apt/sources.list.

You can specify an apt proxy to configure in the container image in the $AUTOPKGTEST_APT_PROXY environment variable. If you have an apt proxy configured on the host, the container will automatically use this, otherwise there is no default.

A container image named autopkgtest/debian:sid, suitable for testing packages that target Debian unstable (sid), can be based on the images available from docker.io:

$ autopkgtest-build-podman --image debian:sid --post-command "apt-get update && apt-get install some-package"

or can be built locally from a minbase tarball generated by mmdebstrap(1):

$ mmdebstrap --variant=minbase sid - | autopkgtest-build-podman --release=sid --tarball=-

podman(1), docker(1), containers-registries.conf(5), autopkgtest-virt-docker(1), autopkgtest(1), /usr/share/doc/autopkgtest/

autopkgtest-build-docker was written by Iñaki Malerba <inaki@malerba.space>

This manpage is part of autopkgtest, a tool for testing Debian binary packages. autopkgtest is Copyright (C) 2006-2014 Canonical Ltd and others.

See /usr/share/doc/autopkgtest/CREDITS for the list of contributors and full copying conditions.

2018 Linux Programmer's Manual