6.4 Deployment & GitHub Actions

The application utilizes GitHub Actions and GitHub Container Registry (GHCR) to automate the deployment lifecycle, cleanly separating development and production environments.

The GitHub Action Pipeline

Located in .github/workflows/publish.yml, a GitHub action runs exactly when changes are pushed to main.

This action behaves as a continuous delivery bridge:

1. It validates out and builds the individual Docker targets defined in the dockerfile (app-stage, scheduler-stage, test-stage).
2. It pushes the sealed images to packages listed under ghcr.io/opentdatach/stop_sync_osm_atlas-*.

Server Setup & Production Execution

For the end server manager, source code does not need to exist on the deployment machine.
The host server requires only:

1. docker-compose.yml
2. .env

To restart or update the instances, the server manager runs the minimal commands:

docker compose pull
docker compose up -d

All images are pulled via layer caching from the registry, skipping any lengthy rebuild times. Volume mounting of code (- .:/app) is explicitly excluded in the production docker-compose.yml.

Local Development vs Production Parity

To guarantee the system works the same locally but handles live code updates, docker-compose.override.yml supplements the baseline when run locally on the host. The override file reinstates build: commands and binds local code, so that standard docker compose up triggers real-time loading while retaining parity with production environments.