Arch Linux provides OCI-Compliant container images in multiple repositories:

• Weekly in the official DockerHub library: podman pull docker.io/library/archlinux:latest or docker pull archlinux:latest
• Daily in our DockerHub repository: podman pull docker.io/archlinux/archlinux:latest or docker pull archlinux/archlinux:latest
• Daily in our quay.io repository: podman pull quay.io/archlinux/archlinux:latest or docker pull quay.io/archlinux/archlinux:latest
• Daily in our ghcr.io repository: podman pull ghcr.io/archlinux/archlinux:latest or docker pull ghcr.io/archlinux/archlinux:latest

Three versions of the image are provided: base (approx. 150 MiB), base-devel (approx. 260 MiB) and multilib-devel (approx. 300MiB) containing the respective meta package. All of them are available as tags with latest pointing to base. Additionally, images are tagged with their date and build job number, f.e. base-devel-20201118.0.9436.

While the images are regularly kept up to date it is strongly recommended running pacman -Syu right after starting a container due to the rolling release nature of Arch Linux.

All the images, with the exception of the official DockerHub library image, are signed by using cosign's keyless signing. The images can be verified with one of the following commands:

$ cosign verify docker.io/archlinux/archlinux:latest --certificate-identity-regexp="https://gitlab\.archlinux\.org/archlinux/archlinux-docker//\.gitlab-ci\.yml@refs/tags/v[0-9]+\.0\.[0-9]+" --certificate-oidc-issuer=https://gitlab.archlinux.org
$ cosign verify quay.io/archlinux/archlinux:latest --certificate-identity-regexp="https://gitlab\.archlinux\.org/archlinux/archlinux-docker//\.gitlab-ci\.yml@refs/tags/v[0-9]+\.0\.[0-9]+" --certificate-oidc-issuer=https://gitlab.archlinux.org
$ cosign verify ghcr.io/archlinux/archlinux:latest --certificate-identity-regexp="https://gitlab\.archlinux\.org/archlinux/archlinux-docker//\.gitlab-ci\.yml@refs/tags/v[0-9]+\.0\.[0-9]+" --certificate-oidc-issuer=https://gitlab.archlinux.org

• Provide the Arch experience in a Docker image
• Provide the simplest but complete image to base, base-devel and multilib-devel on a regular basis
• pacman needs to work out of the box
• All installed packages have to be kept unmodified

 ⚠️⚠️⚠️ NOTE: For Security Reasons, these images strip the pacman lsign key.
 This is because the same key would be spread to all containers of the same
 image, allowing for malicious actors to inject packages (via, for example,
 a man-in-the-middle). In order to create a lsign-key run `pacman-key
 --init` on the first execution, but be careful to not redistribute that
 key.⚠️⚠️⚠️

This repository contains all scripts and files needed to create an OCI image for Arch Linux.

Install the following Arch Linux packages:

• make
• devtools (for the pacman.conf files)
• git (to fetch the commit/revision number)
• podman
• fakechroot
• fakeroot

Make sure your user can directly interact with Podman (i.e. podman info works).

There are multiple make image-XXX targets, where each creates the respective archlinux:XXX image based on the corresponding meta package. Currently those include base, base-devel and multilib-devel.

Daily images are build with scheduled GitLab CI using our own runner infrastructure. Initially root filesystem archives are constructed and provided in our package registry. The released multi-stage Dockerfile downloads those archives and verifies their integrity before unpacking it into an OCI image layer. Images are built using podman, which also publishes them to our external repositories.

Weekly releases to the official DockerHub library use the same pipeline as daily builds. Updates are provided as automatic pull requests to the official-images library, whose GitHub pipeline will build the images using our provided rootfs archives and Dockerfiles.

Changes in Git feature branches are built and tested using the pipeline as well. Development images are uploaded to our GitLab Container Registry.

Every year in June the content of the protected GITLAB_PROJECT_TOKEN variable needs to be replaced. To do this a GitLab admin needs to create a new Access Token with api and write_repository scope and the Maintainer role. This will create a new Bot User which needs to be given access to the protected releases branch.