Build phases

The process is the same as the building process inside a command line using Docker CLI. It is divided into stages as you described them:

1) Waiting for build worker - Quay queries the build worker to see if it's available to take a build job. If a worker is not present or not available ()for example, by doing another build job), the Quay waits until the worker signals that it's available and ready. Once a worker is set up, the 2nd stage begins.
2) Pulling base image - Dockerfile contains a FROM instruction that sets up a base image for the container. The base image is pulled on the build worker and mounted.
3) Priming cache - Quay checks the previous version of the container and indexes the layers. This is to increase build times, layers that are not changed are reused in the new version of the container.

At this point, the normal Docker build procedure starts.

4) Building - Docker runs all the other commands from inside the Dockerfile in the mounted base image, recording all changes in the process as separate layers. The layers inherit all the filesystem data from the previous layer. Once the last command from the Dockerfile is run, the container is formed from all the layers used in the build process.
5) Pushing the container to Quay - the build node sends a signal to Quay that the build process is done and pushes all the layers to Quay. Quay records the Docker container manifest and saves all the layers of the container in the storage and makes appropriate changes in the database to link the new tag with the new layers. If the tag already exists, it edits the database in such a way that the tag points to newly created layers.
6. Complete - once the push to Quay is done and tags are properly saved, the building process is complete and the tags are available inside Quay user interface. The image can now be pulled by Docker command line interface or can be referenced in another Quay container build.

Users can use the API endpoint getRepoBuildStatus to obtain status codes for the builds in progress. The status of the build process is a part of the JSON payload being returned from the API and looks as follows:

{
  "status": {
    "push_completion": 0,
    "current_command": 10,
    "cache_completion": 1,
    "total_commands": 11,
    "pull_completion": 1,
    "heartbeat": 1505831946
  },

The total_commands is the number of commands being run in the build job, where current_command shows numerically what the command is running. Cache_completion's status '1' means that Quay searched through the whole cache in search for potential layers for reusing. Once a build is done, the API request will return the same JSON payload but the status will be an empty set.