Automate building Docker container images #570
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR Adds a Dockerfile to the application to allow for easier building of containers. The existing deploy script does most of the setup on the host rather than within the container. This forces the host to have the required tools and files rather than having these requirements solely within the container. This also meant that the container had to be the same architecture (x86, x86_64, arm, etc) as the building host.
The added Dockerfile also contains two build stages, one which installs the minimal dependencies for pts to run ("light" version) and one which installs packages required by most tests ("full" version). The default when doing a
docker buildis the full version, but adding--target lightwill produce the minimal light build. The full version strictly builds off of the light version, so pulling the full version also pulls the light version, and pulling the light version pulls a significant portion of the full version.This PR additionally adds a GitHub Actions workflow to automatically build and push the containers. It activates on any pushes to the master branch as well as any pushed version tags (tags matching "v*"). The master branch builds will be tagged as "edge" and "edge-light". Builds of version tags will be tagged with major, major and minor, and major and minor and patch (e.g. a tag of "v1.2.3" will create a build with tags of "1", "1.2", and "1.2.3") as well as the "latest" tag. An additional image will be created for the light version with the same tags as the full version but with "-light" appended (e.g. "1-light", "1.2-light", "1.2.3-light", and "latest-light").
These builds are completed for multiple architectures (currently amd64, arm/v7, arm64, and riscv64) with the different versions of the same code combined together within the manifest. This allows a user on any platform to pull the tag "1.2.3" and will select the correct image for their architecture.
This PR currently pushes containers to the GitHub Container Registry (ghcr.io). This simplifies authenticating with the registry (automatic rather than requiring setup like Docker Hub) and uses the repo name as the container name ("ghcr.io/phoronix-test-suite/phoronix-test-suite"). However, this name can easily be changed and another container registry used or added.
TL;DR - adds Dockerfile and auto (multi-architecture) builds using GH Actions, pushing to GHCR using the same name as the repo.