Ilia Denisov
a9087691a3
Five connected cleanups across the dev/CI infrastructure:
1. Drop tools/local-ci/. The standalone Gitea + act_runner stack was
the legacy "offline workflow validator"; the per-stage CI gate now
runs on gitea.lan and the directory was only retained as a
fallback. Removing it leaves no operational dependency: backend,
gateway, and game code have no references; documentation that
pointed at it (CLAUDE.md, docs/ARCHITECTURE.md, ui/docs/testing.md,
tools/dev-deploy/README.md, tools/local-dev/README.md) is updated
in this same change. Historical "Verified on local-ci run N"
markers in ui/PLAN.md are preserved unchanged.
2. Lift the pre-production single-migration rule. The rule forced
every schema delta into 00001_init.sql and required a manual
make clean-data wipe on every backward-incompatible change in
tools/dev-deploy/. Future schema deltas now land as additive
sequence-numbered files (00002_*.sql, …) that goose applies
automatically on backend startup; 00001_init.sql becomes an
immutable baseline. Authoring conventions live in
backend/internal/postgres/migrations/README.md. The chain may be
squashed back into a fresh 00001 as a deliberate one-time
operation before the first production deployment.
3. Document the deployment cadence. The dev environment is
single-tenant: pushes to feature/* run the test workflows
(go-unit, ui-test, integration) only; dev-deploy.yaml fires on
push to development. A workflow_dispatch override on
dev-deploy.yaml lets a developer preview a feature branch on the
shared dev environment before merge; the next merge into
development overwrites the manual deploy idempotently.
4. Scope compose-managed resources by an explicit
galaxy.stack=<local-dev|dev-deploy> label. Both compose files
stamp the label on every service, network, and named volume.
Makefiles in tools/local-dev/ and tools/dev-deploy/ filter their
engine-cleanup operations by (stack-label AND engine OCI title)
so they never touch unrelated workloads on the same daemon.
dev-deploy.yaml gains a pre-`compose up` step that reaps stale
exited/dead containers under the dev-deploy stack label.
5. Backend now stamps the same galaxy.stack=<value> label on every
engine container it spawns, sourced from a new BACKEND_STACK_LABEL
env var (empty → label not applied; legacy-safe). Both compose
files set it to their stack name (local-dev / dev-deploy). The
contract is recorded in docs/ARCHITECTURE.md under
"Container labels". A package-level test in
backend/internal/runtime exercises both the label-present and
label-absent paths.
No tests intentionally regressed: go test ./backend/internal/{config,
runtime,dockerclient} is green, both compose files validate cleanly,
and the backend, gateway, and game modules all build.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
47 lines
2.1 KiB
Markdown
47 lines
2.1 KiB
Markdown
# Backend migrations
|
|
|
|
Goose (`pressly/goose/v3`) migrations embedded into the backend binary
|
|
by `embed.go`. Applied at startup before any listener opens — see
|
|
`internal/postgres`.
|
|
|
|
## Authoring conventions
|
|
|
|
- Each schema change is a new file with a monotonically increasing
|
|
numeric prefix and a snake-case slug:
|
|
`0000N_short_description.sql`. Reuse of a prefix is forbidden once
|
|
the file is merged.
|
|
- `00001_init.sql` is the historical baseline. Treat it as immutable
|
|
history; do not edit it to land new schema. Squashing the chain back
|
|
into a fresh `00001` is reserved for the explicit pre-production
|
|
cut-over.
|
|
- Every file MUST contain both an `-- +goose Up` and `-- +goose Down`
|
|
section, even if Down is a single `DROP …` for the same artefacts.
|
|
Down migrations are exercised by the schema test and serve as the
|
|
documented rollback path.
|
|
- Destructive changes (dropping columns/tables, renaming with data
|
|
loss) MUST be split into at least two migrations so the chain stays
|
|
rollable forward and backward without coordinated code+schema
|
|
windows:
|
|
1. add the new shape, dual-write the data, leave the old shape in
|
|
place;
|
|
2. once all readers have switched, drop the old shape in a follow-up
|
|
migration.
|
|
- Migrations are applied automatically on backend startup, so a fresh
|
|
push to `development` plus the `dev-deploy.yaml` workflow brings the
|
|
long-lived dev database up to head without manual intervention.
|
|
`make -C tools/dev-deploy clean-data` is only needed when a developer
|
|
deliberately wants a fresh database.
|
|
- The integration harness (`backend/internal/postgres/migrations_test.go`)
|
|
spins up a disposable Postgres per run and asserts the final table
|
|
set. When a migration adds or removes tables, update the expected
|
|
list in the same patch.
|
|
|
|
## Pre-production squash
|
|
|
|
The chain may be squashed back into one clean `00001_init.sql` before
|
|
the first production deployment. That is a deliberate, one-time
|
|
operation; until then, additive numbered files are the rule. After the
|
|
squash this file gets a short note that `00001_init.sql` represents
|
|
the production baseline and the policy above continues to apply for
|
|
every later migration.
|