🐥 ci: Build Canary Docker Images

[lia-by-librechat]

Summary

LibreChat already builds release/main and dev Docker images, but there is no corresponding image lane for the repository's canary branch. Using a dev staging image to exercise canary would build the wrong source or overwrite a dev tag. Add a dedicated workflow that publishes two canary-named images using the existing native amd64/arm64 reusable publisher.

A change to a Docker build input on canary (including the first merge of this workflow) runs the build. Manual dispatch is also available, but its publish job explicitly refuses any ref other than refs/heads/canary. Each run checks out its triggering commit SHA, sets BUILD_BRANCH=canary, and publishes both an immutable full-SHA tag and latest within these separate image repositories:

Docker target	Image name
Dockerfile.multi / api-build	librechat-canary-api
Dockerfile / node	librechat-canary

The reusable publisher publishes to GHCR under the repository owner and to the existing configured Docker Hub account, and optionally mirrors to the configured legacy GHCR namespace. These new image names do not overwrite the main/dev images or tags. For deployment, pin the canary SHA tag or digest, not the mutable latest tag. No Kubernetes namespace, cluster or deployment is created here.

Type of change

• Tests / tooling / CI

Testing

• Parsed the YAML using the installed js-yaml package and asserted canary-only push and dispatch guard; first-merge workflow path trigger; immutable github.sha checkout; dual SHA/latest tags; the two Docker targets; noncolliding image names relative to main/dev; the existing publisher secret contract; and native amd64/arm64 manifest merge.
• Prettier and git diff --check pass.
• No TypeScript workspace changes. An actual registry build/publish has not run: the new workflow does not run on a PR. Once merged into canary, the self-trigger path causes a publish from that merge commit; the exact run and image digests must be checked before deploying. The Docker publish secrets/permissions and first registration of the new image repositories will be validated by that run.

Screenshots / recordings

N/A. No application UI change.

Risk / compatibility

This enables automated, potentially expensive two-image/two-architecture builds on canary source changes, following the existing dev workflow's path filters and concurrency pattern. Manual dispatch is fail-closed for non-canary refs. The full SHA tag allows rollback to a known build even if latest advances. Neither cluster provisioning nor staging rollout is part of this PR.

Checklist

• I reviewed the image names and branch guard against main/dev publishing workflows
• YAML parsing and scoped structural/format checks pass
• Exact canary merge-head build/push succeeds in GHCR and Docker Hub
• No dependency or product code changes
• Required documentation PR: N/A

[lia-by-librechat]

Review handoff for exact head c318cac14951ba1df59401e048941baa710a412c: adds a canary-only image build using the existing multi-architecture publisher, with isolated librechat-canary and librechat-canary-api names, immutable SHA tags, a manual ref guard, and a self-triggering path so its merge builds canary. No Kubernetes deployment or namespace changes. Please review trigger/permissions and image-tag isolation; real registry publication starts only after merge.

[danny-avila]

@codex review

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-25T01:23:17.984967Z	c318cac	Manual request

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

LibreChat/.github/workflows/canary-images.yml

Line 1 in c318cac

name: Docker Canary Images Build

Register the canary workflow for Docker retries

When a canary build or registry push fails or times out transiently, it will not receive the automatic retries used by every existing image publisher. .github/workflows/retry-docker-builds.yml subscribes to an explicit workflow-name list on lines 5–11 and retries matching failed runs up to three attempts, but this new Docker Canary Images Build name is absent, so a failed canary publish leaves its images unavailable until someone reruns it manually. Add this workflow name to that subscription list.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".