Skip to content

ci: build and publish images with NEXT_PUBLIC_LOCALE_PREFIX=always#575

Open
HardAndHeavy wants to merge 1 commit into
bulwarkmail:mainfrom
HardAndHeavy:ci/build-always-locale-prefix-image
Open

ci: build and publish images with NEXT_PUBLIC_LOCALE_PREFIX=always#575
HardAndHeavy wants to merge 1 commit into
bulwarkmail:mainfrom
HardAndHeavy:ci/build-always-locale-prefix-image

Conversation

@HardAndHeavy

Copy link
Copy Markdown

Summary

This PR extends the existing GitHub Actions workflow to automatically build and publish Docker images with the NEXT_PUBLIC_LOCALE_PREFIX environment variable set to always. As documented in the README, this configuration is required for users who want to serve the webmail at a subpath to avoid next-intl rewrite loops. This provides pre-built images (-always suffix) for these users, removing the need for them to build their own custom images.

Important: The NEXT_PUBLIC_BASE_PATH is intentionally NOT set in these builds. Each user may have a different subpath (e.g., /webmail, /mail, /apps/email), and since NEXT_PUBLIC_* variables are inlined at build time, hardcoding a specific base path would make the image unusable for most users. Setting only NEXT_PUBLIC_LOCALE_PREFIX=always is the correct approach.

Changes

  • Added new build-always job that builds images with build-args: NEXT_PUBLIC_LOCALE_PREFIX=always only.
  • Added merge-always job that creates a separate multi-arch manifest list with -always suffixed tags (e.g., ghcr.io/bulwarkmail/webmail:1.7.6-always and latest-always).
  • The new images are built for all supported platforms (linux/amd64, linux/arm64) and published alongside the default builds.
  • The existing default builds remain unchanged, ensuring backward compatibility.

Related Issues

Closes the need for users to manually rebuild images when deploying to a subpath. Related to documentation in the README.

Closes #

Type of Change

  • Bug fix (non-breaking change that fixes an issue)
  • New feature (non-breaking change that adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update
  • Refactor / code quality improvement
  • Chore / dependency update / CI change

Checklist

  • I have read the Contributing Guide
  • My code follows the project's code style and conventions (YAML formatting)
  • I have run npm run typecheck && npm run lint and there are no errors (N/A — CI change only)
  • The build passes (npm run build) (N/A — CI change only)
  • I have tested my changes locally — Note: I have replicated the existing job structure and made minimal modifications, following the same logic as the current workflow.
  • I have added or updated documentation if needed — I will update the README in a follow-up PR to mention the -always images if this is merged.
  • I have updated translations (locales/) if my changes affect user-facing text (N/A)
  • I have included screenshots or a screen recording for UI changes (N/A)

Screenshots / Demo

N/A — CI/CD pipeline changes only.

Notes for Reviewers

  • The build-always and merge-always jobs are copies of the build and merge jobs, with build-args: NEXT_PUBLIC_LOCALE_PREFIX=always added.
  • I used flavor: suffix=-always,onlatest=true to ensure that the latest tag also gets the -always suffix, preventing it from overwriting the standard latest image.
  • Important limitation (inherited from the original workflow): These jobs run on both release: published and workflow_dispatch events. If triggered manually from a non-release branch, the latest-always tag could be overwritten with a non-release build. This is a pre-existing issue in the original workflow that this PR does not attempt to fix, as it would require changing the main workflow's behavior and be out of scope for this change. The -always images are primarily intended for release builds.
  • The NEXT_PUBLIC_BASE_PATH is intentionally omitted — users should set it according to their own subpath deployment needs, not via a pre-built image.

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