Chapter 1. Red Hat Quay builds overview
Red Hat Quay builds, or just builds, are a feature that enable the automation of container image builds. The builds feature uses worker nodes to build images from Dockerfiles or other build specifications. These builds can be triggered manually or automatically via webhooks from repositories like GitHub, allowing users to integrate continuous integration (CI) and continuous delivery (CD) pipelines into their workflow.
The builds feature is supported on Red Hat Quay on OpenShift Container Platform and Kubernetes clusters. For Operator-based deployments and Kubernetes clusters, builds are created by using a build manager that coordinates and handles the build jobs. Builds support building Dockerfile on both bare metal platforms and on virtualized platforms with virtual builders. This versatility allows organizations to adapt to existing infrastructure while leveraging Red Hat Quay’s container image build capabilities.
The key features of Red Hat Quay builds feature include:
- Automated builds triggered by code commits or version control events
- Support for Docker and Podman container images
- Fine-grained control over build environments and resources
- Integration with Kubernetes and OpenShift Container Platform for scalable builds
- Compatibility with bare metal and virtualized infrastructure
Running builds directly in a container on bare metal platforms does not have the same isolation as when using virtual machines, however, it still provides good protection.
Builds are highly complex, and administrators are encouraged to review the Build automation architecture guide before continuing.
1.1. Building container images
Building container images involves creating a blueprint for a containerized application. Blueprints rely on base images from other public repositories that define how the application should be installed and configured.
Red Hat Quay supports the ability to build Docker and Podman container images. This functionality is valuable for developers and organizations who rely on container and container orchestration.
1.1.1. Build contexts
When building an image with Docker or Podman, a directory is specified to become the build context. This is true for both manual Builds and Build triggers, because the Build that is created by is not different than running docker build or podman build on your local machine.
Build contexts are always specified in the subdirectory from the Build setup, and fallback to the root of the Build source if a directory is not specified.
When a build is triggered, Build workers clone the Git repository to the worker machine, and then enter the Build context before conducting a Build.
For Builds based on .tar archives, Build workers extract the archive and enter the Build context. For example:
Extracted Build archive
example
├── .git
├── Dockerfile
├── file
└── subdir
└── Dockerfile
Imagine that the Extracted Build archive is the directory structure got a Github repository called example. If no subdirectory is specified in the Build trigger setup, or when manually starting the Build, the Build operates in the example directory.
If a subdirectory is specified in the Build trigger setup, for example, subdir, only the Dockerfile within it is visible to the Build. This means that you cannot use the ADD command in the Dockerfile to add file, because it is outside of the Build context.
Unlike Docker Hub, the Dockerfile is part of the Build context on As a result, it must not appear in the .dockerignore file.
