Lab 2: CI/CD, Warehouse Stack & Release

In this lab you wire the GitHub Actions pipeline to the VM, understand the three-container warehouse application, and ship it — both continuous deploys and versioned releases.

Part 3 of 4 — Overview · Lab 1: Provision & Configure · Operations & Troubleshooting

Phase 3 — Wire Up CI/CD Secrets & Deploy Target

Runs from your control machine with gh.

The warehouse is not deployed by hand. GitHub Actions (.github/workflows/deploy.yml) builds the container images, pushes them to GHCR, then SSHes into the VM to pull and restart them. First you must give the pipeline its target and its secrets.

Step 3.1 — Repository variables (non-secret deploy target)

These tell the workflow where to deploy. They replace values that used to be hardcoded.

gh variable set DEPLOY_HOST --body "__DEPLOY_HOST__"        # VM public IP / hostname
gh variable set DEPLOY_USER --body "__DEPLOY_USER__"        # VM SSH user for deploys
gh variable set DEPLOY_PORT --body "__DEPLOY_PORT__"        # SSH port
gh variable set DEPLOY_PATH --body "__DEPLOY_PATH__"        # repo checkout path on the VM
gh variable list                                          # verify

$ gh variable list
NAME          VALUE                UPDATED AT
DEPLOY_HOST   __DEPLOY_HOST__      just now
DEPLOY_USER   __DEPLOY_USER__      just now
DEPLOY_PORT   __DEPLOY_PORT__      just now
DEPLOY_PATH   __DEPLOY_PATH__      just now

Step 3.2 — The SSH deploy key secret

Generate a dedicated key, authorize it on the VM, upload the private half as a secret:

ssh-keygen -t ed25519 -C "github-actions-deploy" -f ./deploy_key -N ""
 
# Authorize the public key on the VM (match your DEPLOY_* values)
ssh-copy-id -i ./deploy_key.pub -p __DEPLOY_PORT__ __DEPLOY_USER__@__DEPLOY_HOST__
 
# Upload the private key, then destroy the local copies
gh secret set SSH_PRIVATE_KEY < ./deploy_key
rm ./deploy_key ./deploy_key.pub

$ ssh-copy-id -i ./deploy_key.pub -p __DEPLOY_PORT__ __DEPLOY_USER__@__DEPLOY_HOST__
Number of key(s) added: 1

$ gh secret set SSH_PRIVATE_KEY < ./deploy_key
✓ Set Actions secret SSH_PRIVATE_KEY for __GH_OWNER__/mnchtest

GITHUB_TOKEN needs no setup — GitHub Actions provides it per-run and uses it to push/pull images from GHCR (ghcr.io).

Step 3.3 — Application & database secrets

The deploy job regenerates the VM’s .env on every run from these repo secrets (cat > .env <<EOF … EOF over SSH). The VM’s .env is disposable generated state — never hand-edit it. Set each with gh secret set <NAME> --body '<value>':

The image tags (PREFECT_IMAGE / SUPERSET_IMAGE / DAGSTER_IMAGE) are exported inline by the deploy job per run — you don’t set them anywhere. .env.example in the app repo is for local dev only, not the VM.

Step 3.4 — GHCR package visibility (first release only)

The first run creates three packages: ghcr.io/__GH_OWNER__/mnchtest/{prefect,superset,dagster}. They inherit the repo’s visibility, so GITHUB_TOKEN should push/pull fine. If the deploy job’s pull hits 401/403, open each package’s Settings → Manage Actions access and give the repo at least Write access.

Phase 4 — The Warehouse Application

This is what actually runs on the VM.

Three Docker containers run on the VM via docker-compose.yml, all connecting out to the external PostgreSQL server from Phase 3.

Runtime topology

What each container does:

• Prefect — runs the Prefect server (API + UI) and a worker in one container. The worker executes ~60 ingestion deployments (from .prefect/prefect.yaml) on cron schedules, writing into the warehouse’s landing schema. Startup command, in order: start server → poll /api/health until ready → create the default process work-pool → deploy --all → start the worker (foreground).
• Dagster — runs dagster-webserver (UI, port 3000) + dagster-daemon (schedules/sensors). It loads the dbt/ project as Dagster assets and materializes them (dbt build) on the dbt_daily_schedule (0 9 * * * Africa/Kigali, after the overnight ingestion window). That schedule is defined with default_status=RUNNING — load-bearing, because Dagster schedules default to stopped. The dbt/ project is baked into the image at build time, so a .sql change ships automatically on the next CI build — no manual dbt run in prod. Startup: dbt parse (needs runtime DB creds, so it happens at container start) → dagster-daemon (background) → dagster-webserver (foreground).
• Superset — reads the dbt-built marts to render dashboards; stores its own state in superset_db. Startup: superset db upgrade → create admin (skipped after first run) → superset init → superset run on 8088. Requires the ./.superset:/app/pythonpath volume mount for superset_config.py, or it silently falls back to a SQLite metadata store.

Port map

These are the ports your reverse proxy (Step 1.5 / playbook 02) forwards to.

dbt data model

• dbt/models
  • staging — 9 models, clean raw landing data
  • intermediate — 11 models, business logic & indicators
  • marts
    • shared — dim_facilities, fct_hmis_aggregate
    • ebuzima_dq — 22 data-quality models + consolidated_dq

Data quality is measured across six dimensions: accuracy, completeness, consistency, timeliness, uniqueness, validity.

Data sources:

• eBuzima (ERPNext-based EMR) — individual-level ANC/maternity/newborn records, ingested daily.
• HMIS/DHIS2 — facility-level monthly aggregates, ingested on the 20th of each month.

Phase 5 — Deploy & Release

With Phases 1–2 and Phase 3 done, deployment is triggered from GitHub — no builds ever happen on the VM.

Continuous deploy (push to main)

A plain push to main builds :latest images, pushes to GHCR, then SSHes into the VM to:

1. git pull origin main (refresh flow/dbt/config code on the VM),
2. regenerate .env from the GitHub secrets (Step 3.3),
3. docker compose pull && docker compose up -d --remove-orphans.

Cutting a versioned release

Releases are triggered by publishing a GitHub Release, not by pushing a tag directly:

gh release create v1.0.0 --generate-notes

This builds and pushes ghcr.io/__GH_OWNER__/mnchtest/{prefect,superset,dagster}:v1.0.0 (and updates :latest), then deploys that pinned version to the VM.

Watch progress:

gh run watch

$ gh run watch
✓ deploy in 1m42s (ID 123456789)

Local verification before pushing

cp .env.example .env      # fill in real values (local dev only)
docker compose config     # confirms env-var interpolation resolves
docker compose up -d --build

$ docker compose up -d --build
[+] Running 3/3
 ✔ Container mnchtest-prefect-1   Started
 ✔ Container mnchtest-dagster-1   Started
 ✔ Container mnchtest-superset-1  Started

Accessing the running services

GitHub Actions secrets are write-only — there’s no gh command to read one back. To recover the current Superset password, SSH into the VM and cat .env, or check your team’s secret record.

Running dbt manually (development)

In production dbt runs automatically via Dagster’s daily schedule. To run manually while developing:

cd dbt
dbt run
dbt test

Or in the Dagster UI (port 13000): Assets → select dbt assets → Materialize.

Deploying Prefect flows manually

cd .prefect
prefect deploy --all

Clean up

Full teardown of everything this lab deployed:

# stop and remove the running containers on the VM
ssh __DEPLOY_USER__@__DEPLOY_HOST__ -p __DEPLOY_PORT__ "cd __DEPLOY_PATH__ && docker compose down"
 
# delete the GHCR packages if you no longer need the images
gh api -X DELETE /orgs/__GH_OWNER__/packages/container/mnchtest%2Fprefect
gh api -X DELETE /orgs/__GH_OWNER__/packages/container/mnchtest%2Fsuperset
gh api -X DELETE /orgs/__GH_OWNER__/packages/container/mnchtest%2Fdagster
 
# clear the repo secrets and variables set in Phase 3
gh secret list | awk '{print $1}' | xargs -n1 gh secret delete
gh variable list | awk '{print $1}' | xargs -n1 gh variable delete
 
docker compose down    # stop the local verification stack, if you started one

What’s next

The stack is live. Finish with Operations, Troubleshooting & Glossary for day-two tasks — credential rotation, TLS renewal, snapshots — and the cross-layer troubleshooting table.