pipework 0.17.1 → 0.19.0

package/CHANGELOG.md

@@ -1,5 +1,36 @@
 # Changelog
 
+## 0.19.0
+
+- **Breaking: `--allow-destructive` and `--acknowledge-lock` are removed and now fail loudly. Authorization for a hazardous migration is declared in that migration's own file.** A flag authorizes an *invocation*, and invocations live in deploy workflows: the first destructive migration that has to ship puts the flag into CI permanently, and from that moment every later migration is pre-approved by a decision nobody revisits, invisibly, in a file no migration review ever opens. 0.18.0 made the gate see correctly; this makes the gate's answer mean something in an unattended pipeline, which is where migrations actually run.
+
+  A pragma authorizes a *file*:
+
+  ```sql
+  -- pipework:expect-destructive
+  DROP TABLE "graph_co_change_edges";
+  ```
+
+  It is written by the person writing the destructive statement, at the moment they write it. It appears in the diff, so it is reviewed. It is versioned, so history records who approved which drop. It cannot go blanket — a pragma in `0065` says nothing about `0071`, and each hazard class needs its own (`expect-destructive`, `expect-locking`, `expect-dynamic`); declaring one does not declare the others. The deploy command stays a bare `pipework migrate` forever, so there is no flag left to erode. Pragmas are recognized only on their own comment line, so prose mentioning one authorizes nothing, and the tracker's existing content-hash check means one cannot be added to an already-applied migration unnoticed.
+
+  Passing either flag is a hard error naming the pragma to use instead, rather than a silent no-op: a pipeline still passing them is a pipeline that has been running ungated and should find out. `MigrateOptions.allowDestructive` / `.acknowledgeLock` are gone from the programmatic API for the same reason.
+
+- **Behavior change: a migration containing `EXECUTE` is reported as a new `dynamic` hazard.** SQL assembled at runtime is not analyzable by a gate that reads text, so rather than pretend to see through it, the gate names it and asks for `-- pipework:expect-dynamic`. This is what makes the literal handling below safe.
+- **Fix: DDL keywords in string literals no longer raise false hazards.** `INSERT INTO notes VALUES ('a; DROP TABLE decoy;')` drops nothing, and 0.18.0 flagged it. Literal *contents* are now blanked before rules match, because a literal is data — what makes literal text dangerous is something `EXECUTE`ing it, which is structural and now has its own rule, rather than a guess about the text. Dollar-quoted bodies are still scanned (`DO $$ BEGIN DROP TABLE x; END $$` executes during the migration), while literals *inside* those bodies are blanked like any other.
+- **`Severity` gains `'dynamic'`; `MigrationCheckResult` gains `hasDynamic` and `declared`, and each entry in `fileHazards` gains `undeclared`** naming the hazard classes that file raises but does not declare. `formatCheckResult` reports per-file and prints the exact line to add to each migration.
+
+  Upgrading: run `pipework migrate` with no flags. It names every pending migration that needs a declaration and the line to paste. Applied migrations are untouched — the tracker still scopes the scan to pending entries, so history needs no annotation.
+
+## 0.18.0
+
+- **Fix: the migration safety gate no longer skips every statement that has a comment above it.** `splitStatements` split on `;` and then discarded any fragment beginning with `--`. A statement and its preceding comment land in the *same* fragment, so a comment-led statement was thrown away before any hazard rule ran and `checkMigrations` reported the file **clean** — the failure ran in the fail-open direction, and `pipework migrate` applied a comment-led `DROP TABLE` with no `--allow-destructive`. Reported against a codebase where 70 of 93 committed migrations lead with a comment, i.e. most statements in most migrations were never scanned. Comments are now stripped by a scanner rather than used to discard fragments. Issue #334.
+- **Behavior change: upgrading will surface hazards in migrations that previously reported clean.** Nothing about the existing rules changed — these are findings the gate should always have reported. Pending migrations that were passing unattended deploys may now require `--allow-destructive` or `--acknowledge-lock`. Already-applied migrations stay quiet, as before: the tracker scopes the scan to pending entries only.
+- **Fix: statement splitting is now correct inside string literals, quoted identifiers and dollar-quoted bodies.** `;` inside `'…'`, `"…"` or `$$…$$` no longer splits a statement (a function body was previously chopped into fragments), and `--` or `/* */` inside them is no longer mistaken for a comment. Conversely an apostrophe inside a comment (`-- the migration's ancestors`) no longer opens a phantom string literal that swallows the rest of the file — comment and quote state are tracked in one pass, which is the only ordering that gets both right. Block comments nest, per Postgres. `$1` positional parameters are not read as dollar quotes. DDL inside a string literal is still matched, deliberately: `EXECUTE 'DROP TABLE …'` is a real drop.
+- **Feature: `ADD COLUMN … NOT NULL` without a `DEFAULT` is now reported** as a locking hazard (`--acknowledge-lock`), not a destructive one — on a non-empty table it aborts the deploy rather than losing data. The gate previously covered only `ALTER COLUMN … SET NOT NULL`, leaving it narrower than "block destructive DDL in production" implied.
+- **Fix: hazard excerpts now show the DDL instead of the comment above it**, and a final statement with no trailing semicolon is scanned rather than dropped.
+- **Fix: the migration *runner* no longer shreds a statement containing a `;` inside a block comment or a quoted identifier.** `parseStatements` learned string literals and dollar-quoted bodies in 0.15.x (#317) but not these two, so `ALTER TABLE "weird;name" …` and `… /* one; two */ …` were split into fragments Postgres rejects. Runner and gate now share one scanner, which is why the two could disagree about statement boundaries in the first place.
+- **Fix: `pipework generate` now rewrites a commented `CREATE INDEX` to `CONCURRENTLY`.** The post-processor skipped any `;`-fragment beginning with `--`, so an index creation with an explanatory comment above it kept its exclusive lock — silently losing the safety property that pass exists to add. It now matches against comment-stripped SQL, and a `CREATE INDEX` mentioned only inside a comment is (correctly) not rewritten.
+
 ## 0.17.1
 
 - **Fix: 0.16.0's identity refusal no longer fires on an `appUrl`/`appTestUrl` value that transaction isolation never dials.** The refusal's claim — "test isolation is defeated" — was untrue for that arm under the default strategy: transaction isolation registers its single rolled-back connection as the pool override under the database's *base* key, and `getOrCreate(config, 'app')` falls back to that base override when no role-specific one is registered, so **the app-role pool is never created** and the app-test value only ever has to satisfy config resolution. Refusing a provably-inert value is a false positive, and it blocked consumers whose committed `.env.example` deliberately sets the app-test var equal to the app var for exactly this reason. Identical app-role values now resolve when the strategy never creates that pool, and are refused wherever it does — the refusal message then names the carve-out and the strategy that voided it, so a reader can see why the other case passes.