A release-time check that answers, for a release candidate: does this bundle introduce schema changes that make the proposed version bump wrong?
A stack-pin diff is just version: 1.5.3 → 2.0.0 across a dozen charts. Nothing in it says whether a migration landed. In a monorepo that evidence is computable rather than something a human has to remember to declare — and a computed diff cannot be forgotten, whereas a declaration in a PR from two months ago can.
Shape: a shared Go library with per-stack configuration, so all three stacks under deploy/stacks/ share one implementation and can diverge in policy declaratively.
tools/stack-upgrade-policy/ — resolves the stack's latest release tag, diffs it against HEAD over that stack's declared migration paths, classifies each changed file as additive or destructive (DROP, TRUNCATE, ALTER … DROP), flags deleted migration files, and compares the evidence against the proposed version bump.tools/ci/check-stack-upgrade-policy — bash entrypoint mirroring tools/ci/chart-service-edge (resolves repo root, builds the binary, propagates the real exit code). Takes --stack <id>.deploy/stacks/<stack>/upgrade-policy.yaml — per-stack config declaring which paths count as migration evidence. self-managed gets migrations/cassandra and migrations/openbao; the other two start empty, making the check a no-op until they need it.
Decision table: no migration changes → pass. Additive only → pass, report them. Destructive changes or deleted migration files with a non-major proposed bump → fail with the file list. Destructive with a major bump → pass, report. The evidence report prints on every run, not only on failure.
The proposed bump comes from the existing tools/ci/release-bump-type for-branch logic rather than a new mechanism.
A release-time check that answers, for a release candidate: does this bundle introduce schema changes that make the proposed version bump wrong?
A stack-pin diff is just
version: 1.5.3→2.0.0across a dozen charts. Nothing in it says whether a migration landed. In a monorepo that evidence is computable rather than something a human has to remember to declare — and a computed diff cannot be forgotten, whereas a declaration in a PR from two months ago can.Shape: a shared Go library with per-stack configuration, so all three stacks under
deploy/stacks/share one implementation and can diverge in policy declaratively.tools/stack-upgrade-policy/— resolves the stack's latest release tag, diffs it againstHEADover that stack's declared migration paths, classifies each changed file as additive or destructive (DROP,TRUNCATE,ALTER … DROP), flags deleted migration files, and compares the evidence against the proposed version bump.tools/ci/check-stack-upgrade-policy— bash entrypoint mirroringtools/ci/chart-service-edge(resolves repo root, builds the binary, propagates the real exit code). Takes--stack <id>.deploy/stacks/<stack>/upgrade-policy.yaml— per-stack config declaring which paths count as migration evidence.self-managedgetsmigrations/cassandraandmigrations/openbao; the other two start empty, making the check a no-op until they need it.Decision table: no migration changes → pass. Additive only → pass, report them. Destructive changes or deleted migration files with a non-major proposed bump → fail with the file list. Destructive with a major bump → pass, report. The evidence report prints on every run, not only on failure.
The proposed bump comes from the existing
tools/ci/release-bump-type for-branchlogic rather than a new mechanism.