CI/CD Pipeline

The docker-openresty images are built, tested, and published through an automated Continuous Integration and Continuous Deployment (CI/CD) pipeline.

CI Providers

The project uses two CI providers to cover the different operating systems:

  • Travis CI: Used for building all Linux-based images across multiple architectures (amd64, aarch64, s390x). The configuration is defined in .travis.yml.
  • Appveyor: Used for building the Windows-based images. The configuration is defined in appveyor.yml.

Build Process

The pipeline is structured in stages to manage the build process efficiently, especially for multi-architecture images.

  1. Build Stage: Individual jobs compile and build the Docker image for each specific flavor and architecture (e.g., jammy-amd64, alpine-aarch64). This is handled by the docker_build_and_push_flavor.sh script.

  2. Manifest Stage: After all architecture-specific images for a flavor are built and pushed, a subsequent job creates and pushes a Docker manifest list. This manifest list is what allows a single tag (e.g., openresty/openresty:jammy) to work across multiple architectures. This is handled by the docker_manifest.sh script.

  3. Fat Build Stage: "Fat" images, which are based on other images, are built in a later stage to ensure their base image is already available.

  4. Fat Manifest Stage: Manifests for the fat images are created.

Build Scripts

The CI jobs execute a set of shell scripts to handle the Docker commands:

  • docker_build_and_push_flavor.sh: Builds and pushes a single image for a specific flavor and architecture. It handles tagging for both master branch builds and versioned Git tags.
  • docker_build_and_push_flavor_fat.sh: A specialized version for building -fat images, ensuring it pulls the correct base image tag.
  • docker_manifest.sh: Uses docker manifest create and docker manifest push to assemble the multi-arch images.
  • docker_tag_alias.sh: Creates alias tags, for example, making centos-rpm an alias for centos.

This structured, script-driven approach ensures that the build process is repeatable, transparent, and maintainable.