dry-run is ignored when baseline argument is passed to migrate apply

[dantheman39]

Hello atlas team!

The other day our team was applying migrations for the first time to an existing database. We ran migrate apply --dry-run --baseline <version> to see what would be run. The expectation was that no changes would be made to the database. However, it seems like the --dry-run argument has no effect when --baseline is present: the atlas_schema_migrations table was created and that version was marked as completed.

As this didn't actually touch our data this was not a major deal, but with some nervous people on the call, you can understand that unexpected behavior like this the first time we ran against our staging database didn't put them at ease 😆 . Hopefully you agree that this behavior is worth changing and hopefully it's easy to do so.

Expected behavior: when --dry-run is included, no changes are made to the database.

Observed behavior: when --baseline and --dry-run appear together, changes are made to the database. Example:

Reproducer

Commands run were:

docker compose up -d
atlas migrate status --env local
atlas migrate apply --env local --dry-run --baseline 20241213151219
atlas migrate status --env local

Here's a zip:
baseline-bug.zip

But here I'll reproduce those files so readers don't have to download the zip if they don't want to.

atlas.hcl

env "local" {
  src = "file://schema.sql"
  url = "postgres://postgres:[email protected]:5432/postgres?&sslmode=disable"
  dev = "docker://postgres/17/dev"
  format {
    migrate {
      diff = "{{ sql . \"  \" }}"
    }
  }
}

docker-compose.yml

services:
  db:
    image: postgres:17-bookworm
    environment:
      - "POSTGRES_PASSWORD=postgres"
      - "PGUSER=postgres"
    ports:
      - "5432:5432"

schema.sql

CREATE TABLE table1(name TEXT);
CREATE TABLE table2(name TEXT);
CREATE TABLE table3(name TEXT);

migrations/20241213150809_table1.sql

-- Create "table1" table
CREATE TABLE "public"."table1" (
  "name" text NULL
);

migrations/20241213151219_table2.sql

-- Create "table2" table
CREATE TABLE "public"."table2" (
  "name" text NULL
);

migrations/20241213151310_table3.sql

-- Create "table3" table
CREATE TABLE "public"."table3" (
  "name" text NULL
);

migrations/atlas.sum

h1:WejeAEw+eU/InKxAUCuDta/9eH3X/vFDixKaS3JAhDI=
20241213150809_table1.sql h1:7TdpkQr6YvX/gmNQ0T03qqW6HzWWxnD6iEFtjhRiOQE=
20241213151219_table2.sql h1:02HSpDqJr2OELcVNL784T1ysrJ++90M0ll1nZUxgQM8=
20241213151310_table3.sql h1:7a0vFj1mXJpPniycDgncZSTm/3QeznbEl7me43wwDgg=

[a8m]

Thanks for raising this up, @dantheman39.

What happened here is that the baseline was marked in the database, but no migrations were applied to it (it's only stored in Atlas' revisions table). This happened because baseline resolving/marking runs in a different stage, before migrations are executed.

I think we should change --dry-run to include baseline as well. We'll handle this soon.