feat: add docker images

[KyleTryon]

This pull request introduces support for publishing pre-built Docker images for both the API and App components, streamlining deployment and updating documentation to guide users through the new workflow. The changes automate image builds and pushes on releases, update deployment instructions to recommend using pre-built images, and ensure version information is consistently embedded in the frontend. The most important changes are grouped below:

Continuous Deployment & Docker Workflow

• Added a new GitHub Actions workflow (.github/workflows/docker-publish.yml) that builds and publishes Docker images for API and App to GitHub Container Registry on release or manual trigger. This workflow handles version tagging, multi-arch builds, and provides a summary of published images.
• Updated docker-compose.yml to support both source builds and pre-built images, with image references for API and App that use the VERSION environment variable and proper build args for versioning. [1] [2]
• Updated packages/app/Dockerfile to accept and use a VITE_APP_VERSION build argument, ensuring the frontend displays the correct version string.
• Added a build script (scripts/docker-build.sh) that sets the frontend version from the current git tag or commit when building from source.
• Changed the docker:build script in package.json to use the new build script, embedding version info automatically.

Documentation Updates

• Updated README.md and docs/deployment.md to recommend using pre-built Docker images for faster and more reliable deployment, including instructions for pinning versions, updating, and embedding version info in the frontend. Both methods (pre-built and source builds) are documented, with clear advantages and usage steps. [1] [2] [3] [4] [5] [6] [7] [8]

These changes greatly improve the deployment experience, making it easier to use, update, and verify TuvixRSS installations with Docker.

[Copilot]

Pull request overview

This pull request introduces comprehensive Docker image publishing infrastructure for TuvixRSS, enabling users to deploy using pre-built images from GitHub Container Registry or build from source. The changes add automation for building and publishing multi-architecture Docker images, update deployment workflows, and enhance documentation with detailed instructions for both deployment methods.

Changes:

• Added GitHub Actions workflow for automated Docker image building and publishing on releases
• Updated docker-compose.yml to support both pre-built images and source builds with version tagging
• Enhanced app Dockerfile to accept version build argument for displaying version in settings
• Created build script that automatically embeds git version information when building from source

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
.github/workflows/docker-publish.yml	New workflow that builds and publishes Docker images to GHCR on releases, with multi-arch support and semver tagging
docker-compose.yml	Added image references for pre-built images, VITE_APP_VERSION build arg, and removed pull_policy directives
packages/app/Dockerfile	Added VITE_APP_VERSION build argument to embed version information in frontend
scripts/docker-build.sh	New build script that extracts git version and passes it to docker-compose build
package.json	Updated docker:build script to use new build script for version embedding
README.md	Added comprehensive quick start instructions for both pre-built images and source builds
docs/deployment.md	Extensive documentation updates covering pre-built images, source builds, version pinning, and updates

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

There's a port mismatch in the documentation. The app container runs on port 8080 internally (as shown in packages/app/Dockerfile line 78 and docker-compose.yml line 59 which maps 5173:8080), but this documentation states to check "http://localhost:5173/health". While 5173 is the correct external port to use, it's important to be consistent. The same issue appears in the documentation at line 385.

Suggested change

	curl http://localhost:5173/health
	curl http://localhost:5173/health # app container listens on 8080, exposed on host as 5173 via docker-compose

[Copilot]

There's a mismatch between the image name in docker-compose.yml and what will be published by the GitHub Actions workflow. The workflow uses ${{ github.repository }}/api which will be TechSquidTV/Tuvix-RSS/api. GitHub Container Registry normalizes this to lowercase techsquidtv/tuvix-rss/api, but docker-compose.yml references techsquidtv/tuvixrss/api (without the dash). This means when users try to pull the pre-built images, they won't be found. The image name should be ghcr.io/techsquidtv/tuvix-rss/api:${VERSION:-latest} to match what's published. The same issue exists for the app image at line 49.

[Copilot]

The same image name mismatch exists here for the app image. It should be ghcr.io/techsquidtv/tuvix-rss/app:${VERSION:-latest} (with dash) to match what will be published by the GitHub Actions workflow.

Suggested change

	image: ghcr.io/techsquidtv/tuvixrss/app:${VERSION:-latest}
	image: ghcr.io/techsquidtv/tuvix-rss/app:${VERSION:-latest}

[Copilot]

The documentation uses inconsistent version numbers in examples. Lines 286-293 use v0.6.1 as the example version, while lines 315, 412, and 427 use v0.7.0. For consistency and to avoid confusion, consider using the same version number throughout the documentation, or use a placeholder like v1.2.3 or vX.Y.Z to make it clear these are just examples.

Suggested change

	export VERSION=v0.7.0 # Or update in .env
	export VERSION=v0.6.1 # Or update in .env

[Copilot]

The port mapping in this documentation example is incorrect. It shows 5173:80 but the actual docker-compose.yml (line 59) and the app Dockerfile (line 78) use port 8080 internally, not 80. This should be 5173:8080 to match the actual configuration.

Suggested change

	- "5173:80"
	- "5173:8080"

[Copilot]

The semver tag patterns will not work correctly when combined with the is_default_branch condition for the latest tag. The type=semver patterns require a version tag (e.g., v1.0.0) to be present, but is_default_branch checks if the current branch is the default branch. When this workflow is triggered by a release event with a version tag, the checkout will be at that tag reference, not on the default branch, so is_default_branch will always be false. This means the latest tag will never be applied to release builds.

Consider removing the enable={{is_default_branch}} condition from the latest tag line, or change the condition to check if it's a production release (e.g., not a prerelease). The same issue exists in the app image configuration at lines 119-123.

Suggested change

	type=raw,value=latest,enable={{is_default_branch}}
	type=raw,value=latest

[Copilot]

The same issue with is_default_branch exists here for the app image. When triggered by a release event, the workflow will be at a tag reference, not on the default branch, so latest tags will never be applied. Consider removing enable={{is_default_branch}} or using a different condition that checks if this is a production release.

Suggested change

	type=raw,value=latest,enable={{is_default_branch}}
	type=raw,value=latest