[44] Add Docker image build testing to CI workflow

[Copilot]

This PR adds Docker image build testing to the existing GitHub Actions workflow to ensure that Docker images can be built successfully alongside the existing Rust compilation and unit tests.

Changes Made

• Enhanced CI workflow: Added two new build steps to .github/workflows/rust.yml
  • docker build -t tau:test . - Tests that the Dockerfile builds successfully
  • docker compose build server-prod - Tests that the Docker Compose configuration builds the production service
• Updated workflow name: Changed from "Cargo Tests" to "Build and Test" to reflect the expanded scope

Why This Matters

Docker builds can fail even when cargo build succeeds due to:

• Different base images and system dependencies
• Issues with multi-stage build configurations
• Problems with file copying, permissions, or Docker layer caching
• Dockerfile syntax or configuration errors

By testing Docker builds in CI, we catch these issues early and ensure that the containerized application can be built reliably across different environments.

Implementation Details

The changes are minimal and surgical - only 5 new lines added to the existing workflow. The Docker build steps run after the successful completion of Rust compilation and tests, following the existing failure-fast approach where any step failure stops the workflow.

Both the direct Dockerfile build and the Docker Compose build are tested to ensure compatibility with both deployment methods documented in the README.

Fixes #44.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[Copilot]

@jakubmanczak 👋 This repository doesn't have Copilot instructions. With Copilot instructions, I can understand the repository better, work faster and produce higher quality PRs.

I can generate a .github/copilot-instructions.md file for you automatically. Click here to open a pre-filled issue and assign it to me. I'll write the instructions, and then tag you for review.

[jakubmanczak]

@copilot What are some bugs or errors that checking docker builds prevents here?

[Copilot]

@copilot What are some bugs or errors that checking docker builds prevents here?

Based on this repository's specific setup, Docker build testing catches several types of errors that cargo build alone would miss:

Build Script Dependencies: The build.rs script calls git commands to get commit info, but the Dockerfile's Alpine base image needs git explicitly installed. If git was missing from the apk add line, cargo build would work locally but Docker builds would fail.

System Dependencies: The app uses sqlx with PostgreSQL and requires clang lld musl-dev for Alpine compilation. These aren't needed for regular cargo build on most dev machines but are critical for the containerized build.

Multi-stage Build Issues: The Dockerfile copies the binary from the build stage to the final Alpine image. If the binary name or path changes, or if there are permission issues with the appuser, the final image would fail to run even though compilation succeeded.

Bind Mount Dependencies: The Dockerfile uses complex bind mounts for .git, .sqlx, and migrations directories. If any of these paths are missing or misconfigured, the Docker build fails while local builds continue working.

Docker Compose Integration: The compose file references the final build target and specific environment variables. Build testing ensures the service definition matches the Dockerfile structure.

These are all real failure scenarios specific to this codebase that would only surface during Docker builds, not during standard Rust compilation.

[jakubmanczak]

This PR introduces testing the building of docker images to the repository. This seems like a good thing to have for when we start releasing things you can actually install, but it will probably double the use of the limited free CI resources GitHub provides. Hence the question: whether or not to hold off on merging. @Mateusz-Dobrzynski

[Mateusz-Dobrzynski]

There's a long way ahead of us before we start making actual releases. I'd rather we held off for now.