Deployment

How it works

This repo deploys as a pointer, not a copy. No source, dbt project, or manifest ever leaves the repo — the orchestration deployment serves this location’s image over gRPC.

On every push to main, the deploy.yml workflow:

1. Validates the Definitions graph — CI imports core_data_updater.main exactly as Dagster will load it, so a location that cannot import never reaches the cluster.
2. Builds the container image and pushes it to ghcr.io/null-capital/core-data-updater, tagged with the immutable commit SHA.
3. Dispatches register-dagster-location to the orchestration repo with the image repository, the SHA tag, and the module path. Orchestration validates, renders the location into its registry, and commits — the Dagster deployment then serves this image over gRPC.

The first rollout is born stopped

A freshly registered location starts with nothing running. The intended sequence:

1. Confirm the location loads cleanly in the Dagster UI.
2. Launch a manual canary run of a representative job.
3. Enable only the schedules and sensors you actually intend to run.

Nothing materializes until you turn it on — a bad first registration can never start writing data on its own.

Rolling forward and back

Every registration points at an immutable SHA. To roll back, re-register a known-good SHA (re-run the deploy workflow from the old commit, or trigger it manually via GitHub Actions → “Run workflow” on deploy.yml). The orchestration registry history is the audit trail of what served when.

Local parity

./run local starts dagster dev -m core_data_updater.main — the same module CI validates and production serves, so what loads locally is what deploys.