Skip to content

WIP #731: Build images for linux/amd64 and linux/arm64 #755

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

Open
wants to merge 38 commits into
base: main
Choose a base branch
from

Conversation

basictheprogram
Copy link

@basictheprogram basictheprogram commented May 17, 2025

I understand Circle CI is the CI of choice. I did not have a Circle CI account. I know little about Circle CI. I could not get the Circle CI changes from #731 to work. Tried to build an ARM image with Circle CI and failed.

Looks like PR #741 was closed with unmerged commits? And I do not see any ARM images on DockerHub.

This PR adds a GitHub workflow that will create docker images for

  • mailman-core
  • mailman-web
  • postorius

For

  • linux/amd64
  • linux/arm64

using

  • alpine3
  • alpine3.20
  • alpine3.21
  • alpine3.21.3

I think that covers all the base images I saw in the FROM in the Dockerfiles.

This GitHub strategy matrix creates 12 docker images, they can be viewed at My Hub.

Looking at the build.sh only the Dockerfile.dev is used?

I followed the variable naming conventions.

You can change the

Allow action on push to main and issue-731 branches
- Refactor docker-login-action from Docker-based to composite to support step usage
- Update docker-build.yml to provide DOCKERHUB_USERNAME and DOCKERHUB_TOKEN secrets to the login action
All matrix jobs to continue regardless of outcome
Using image_name without the inputs
- Trigger workflow on version tags matching 'v*'
- Introduce `version` job to extract semantic version components (major, minor, full)
- Make `build` job depend on `version` and pass version metadata to build-action
- Enable multi-version tagging support (vX.Y.Z, vX.Y, vX) for Docker images
- Removed the separate 'version' job in favor of an inline step in the 'build' job
- Version info is now extracted directly from the tag if available, or defaults to 0.5.2
- Simplifies workflow structure while maintaining version tagging behavior
… the loop —

those expressions are only parsed by GitHub Actions outside the script block.
Inside the run: | block (a Bash script), they become plain text strings.
…ix support

  - Remove hardcoded version inputs from build-action
  - Add automatic extraction of commit ID and version from GITHUB_REF
  - Tag rolling images with rolling-YYYYmmDD format
  - Extend build matrix to support multiple alpine_version and image types (core, web, postorius)
  - Consolidate build steps into a single matrix-based loop for clarity and maintainability
- Removed `platform` as an input from the `build-action` composite action.
- Updated `docker buildx build` to use multi-arch build for `linux/amd64,linux/arm64` by default.
- Simplified version fallback logic in `action.yml`.
- Updated `docker-build.yml` workflow to drop matrix strategy for platform and removed related references.
- Added `ARG ALPINE_VERSION` and updated `FROM` directives in Dockerfiles (core, postorius, web) to use it
- Extended GitHub Actions matrix to include general `3` tag alongside specific versions (3.20, 3.21, 3.21.3)
- Retained previous `FROM alpine:x` lines as comments for reference
…bers, and

3.20 is the same as 3.2 in float notation.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant