feat: add version tags to Docker images

[CommitToday]

Overview This pull request addresses issue #3051 by adding version tags to the Docker images during the build and push process. This will allow for better image management and rollback capabilities.

Checklist

• [x] Code changes have been implemented
• [x] Docker build and push workflows have been updated
• [x] Dockerfiles have been modified to accept version arguments

Proof The changes modify the GitHub Actions workflow to tag Docker images with both latest and the current version. The Dockerfiles are updated to accept the VITE_APP_VERSION argument. This ensures that each image build includes a version tag, improving traceability and deployment management.

Closes #3051

Summary by CodeRabbit

• Chores
  • Deployment now builds and pushes versioned container images (alongside "latest") for client, server, and database, improving release traceability.
  • The release pipeline computes and injects the app version into client builds so the frontend reflects build versions.
  • Build ordering and multi-architecture pushes updated to ensure consistent version-tagged artifacts.

[coderabbitai[bot]]

[!NOTE]

.coderabbit.yml has unrecognized properties

CodeRabbit is using all valid settings from your configuration. Unrecognized properties (listed below) have been ignored and may indicate typos or deprecated fields that can be removed.

⚠️ Parsing warnings (1)

Validation error: Unrecognized key(s) in object: 'release_notes'

⚙️ Configuration instructions

• Please see the configuration documentation for more information.
• You can also validate your configuration using the online YAML validator.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Walkthrough

CI workflow now extracts a VERSION via git describe, exposes it to builds, and pushes images tagged with both :latest and :<VERSION>; Dockerfiles were updated to accept ARG VITE_APP_VERSION in frontend and app stages to propagate the version into image builds.

Changes

Cohort / File(s)	Change Summary
CI/CD workflow .github/workflows/deploy-images.yml	Added a "Get version" step (compute VERSION from git describe), set fetch-depth: 0 on server checkout, export VERSION to env, pass version into builds, and push both :latest and :<VERSION> tags for client, server, mongo, and mono images.
Dockerfiles — ARM server docker/dist-arm/server.Dockerfile	Added ARG VITE_APP_VERSION to the frontend-build stage to expose version during the frontend build.
Dockerfiles — Mono server docker/dist-mono/server.Dockerfile	Added ARG VITE_APP_VERSION declarations to the frontend-build stage and the app stage so VITE_APP_VERSION is available across build stages.

Sequence Diagram

sequenceDiagram
    participant GH as GitHub Actions
    participant Git as Git Repo
    participant Docker as Docker Build
    participant Reg as Container Registry

    GH->>Git: checkout (fetch-depth: 0)
    GH->>Git: run `git describe` -> VERSION
    Note right of GH: export VERSION to job env
    GH->>Docker: build client (build-arg VITE_APP_VERSION=VERSION)
    GH->>Docker: build server/mongo/mono (pass VERSION where applicable)
    Docker->>Reg: push image:latest
    Docker->>Reg: push image:VERSION
    Note over Reg: Both tags available for deployment

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

• Areas to verify:
  • git describe produces the intended format in all branches/tags used by CI.
  • fetch-depth: 0 is set wherever VERSION is computed.
  • All image build steps receive VITE_APP_VERSION where needed and Dockerfiles reference it correctly.
  • Tagging/pushing logic includes both architectures and matches registry tag expectations.
  • Ensure removal of server VITE_APP_VERSION build-arg (if deliberate) does not break server image contents.

Poem

🐰 I hopped through commits and found a name,
Tags now wear numbers and not just "latest" fame.
From git describe I pull the thread,
Two tags now sit atop each sled.
Hop, build, push — a tidy game.

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The PR description addresses the issue number and outlines the key changes, but does not follow the repository's required template structure and is missing several required checklist items.	Use the repository's required PR description template, complete all checklist items (especially deployment testing and self-review), and ensure all required sections are properly filled out.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'feat: add version tags to Docker images' accurately and specifically describes the main change in the PR: adding versioned tags to Docker images.
Linked Issues check	✅ Passed	The PR successfully implements the core requirement from #3051: adding version tags to Docker images. Changes include workflow updates to tag with version numbers and Dockerfile modifications to accept version arguments.
Out of Scope Changes check	✅ Passed	All changes are directly related to implementing version tagging for Docker images as specified in #3051. Modifications to workflows and Dockerfiles align with the stated objectives.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• [ ] Create PR with unit tests
• [ ] Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}