-
-
Notifications
You must be signed in to change notification settings - Fork 0
ci(docker-ci): split publish into per-arch jobs and add robust publis… #29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
…h/manifest flow - Replace single multi-arch `publish` job with per-arch jobs: publish-amd64, publish-arm64, publish-armv7 - Add publish-manifest job that assembles multi-arch manifests from per-arch staging images - Push per-arch "staging" tags and capture metadata (metadata-*.json) to extract image digests as job outputs - Add retry/backoff loops for per-arch builds and manifest creation to improve reliability - Use per-arch QEMU/platform settings and explicit buildx args (provenance mode, metadata-file, cache-from/to, labels) - Create bookworm compatibility tags for v2 trixie images by aliasing the multi-arch manifest (with retries) - Update Trivy SARIF filenames to include architecture and adjust references to staging images
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR refactors the Docker multi-architecture build process from a single unified build job to separate per-architecture jobs followed by manifest assembly. The change implements a staging approach where each architecture (amd64, arm64, armv7) is built independently with staging tags, then combined into multi-arch manifests.
- Splits the single
publishjob into three separate architecture-specific jobs:publish-amd64,publish-arm64, andpublish-armv7 - Adds a new
publish-manifestjob that creates multi-arch manifests from the per-architecture staging images - Implements retry logic for build and manifest creation operations to improve reliability
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Matrix jobs with strategy cannot reliably expose outputs due to conflicts between matrix combinations. The digest outputs in publish-amd64, publish-arm64, and publish-armv7 jobs cannot be reliably consumed and should be removed. The manifest assembly job still functions correctly as it assembles manifests from the staging tags (not from job outputs), so this removal does not break the workflow.
Changed backoff calculation from 2 ** ATTEMPT to 2 ** (ATTEMPT - 1) to produce more reasonable retry intervals: - Old: 2s, 4s, 8s (starting too short after first failure) - New: 1s, 2s, 4s (more appropriate for transient registry issues) Applied to all retry loops in: - publish-amd64 build step - publish-arm64 build step - publish-armv7 build step - DockerHub manifest creation - GHCR manifest creation - Quay manifest creation - Bookworm compatibility tag creation
Changed backoff calculation from 2 ** (ATTEMPT - 1) to 5 * 2 ** (ATTEMPT - 1) to produce more appropriate retry intervals for transient registry issues: - Old: 1s, 2s, 4s (too aggressive for registry recovery) - New: 5s, 10s, 20s (gives transient issues time to resolve) This is more effective for handling temporary API rate limits, service disruptions, and network issues that typically need 5+ seconds to recover. Applied to all retry loops: - Per-arch build steps (amd64, arm64, armv7) - Manifest creation (DockerHub, GHCR, Quay) - Bookworm compatibility tag creation
…tial backoff Adds 3-attempt retry loop with 5s/10s/20s exponential backoff for s6-overlay wget downloads. This addresses transient network timeouts (HTTP 28 timeout) that occur during Alpine builds, which is a common issue with external repository downloads during Docker builds. The retry logic: - Attempts download up to 3 times - Uses 5 * 2^(ATTEMPT-1) backoff (5s, 10s, 20s) - Cleans up partial downloads before retry - Provides clear logging of retry attempts - Fails fast with descriptive error if all attempts fail
…in v1 Adds 3-attempt retry loop with 5s/10s/20s exponential backoff for: 1. install-php-extensions script download from GitHub 2. PHP extension compilation and installation This addresses transient network timeouts that occur on both Alpine and Debian builds. The retry logic handles: - Network timeouts during curl download - Compilation/installation failures due to transient issues - Clear logging of retry attempts and failures Each layer has independent retry loops for robustness.
Replace bash-specific exponentiation (5 * 2 ** (ATTEMPT - 1)) with POSIX sh-compatible case statement for hardcoded backoff values: - ATTEMPT 1: 5 seconds - ATTEMPT 2: 10 seconds - ATTEMPT 3: 20 seconds This fixes 'arithmetic expression: expecting primary' errors in Alpine and Debian builds which use /bin/sh instead of bash. Applies to both: - Dockerfile.v1: install-php-extensions download and installation - Dockerfile.v2: s6-overlay download
Change base image from docker.io/library/php to public.ecr.aws/docker/library/php to avoid Docker Hub's unauthenticated pull rate limits (100 pulls per 6 hours). AWS ECR Public Gallery has no rate limits for public images and is a reliable mirror for Docker Hub's official images. This matches the approach already used in Dockerfile.v2. Fixes: 'toomanyrequests: You have reached your unauthenticated pull rate limit'
…h/manifest flow
publishjob with per-arch jobs: publish-amd64, publish-arm64, publish-armv7