0.1.0: the schema squashed into one migration per context, and an encryption check that can decide

[kisielewski]

Everything 0.1.0 needs from this repository — and the first CI run this branch has ever had, since ci.yml triggers on main and pull requests only.

The squash

Eight migrations and one became version_0_1_0, named for the release that creates the schema. That is the standing rule from now on: before each release the migrations added since the previous one become one, called version_<major>_<minor>_<patch>. Only unreleased migrations are ever squashed, so no released history row is removed and no released database is stranded.

Carried across by hand: the FileContents block and its SET STORAGE EXTERNAL, which is not an EF entity and no regeneration produces. Dropped on purpose: three column defaults — EvaluationJobs.Releases, EvaluationJobs.Refunds, Instance.ShowHero — each left by an AddColumn backfilling a table that already held rows. A table created in one statement has none, the model declares no default for any of them, and each has a CLR initializer.

Verified by comparing schemas, not by reading the generated file. pg_dump --schema-only of an empty database migrated by the old chain and by the new one: 2610 lines each, 53 tables, 102 indexes, 4 check constraints, 61 foreign keys on both sides. The whole difference is pg_dump's session token, column order inside two tables, and those three DEFAULTs. RunnerTags' '{}'::text[] survives, because that one is in the model. One history row per context afterwards.

docs/RELEASE.md carries the procedure and, with it, the case this release does not exercise: from 0.1.1 the squash is a delta — released migrations stay, the snapshot rolls back to the released state, every backfill decision is made again, and a schema dump stops being the whole proof.

The encryption check could not decide what it was asked

The disk grep behind §13.3's last item was unsound. Measured against SeaweedFS: the object's bytes are on disk, complete and contiguous — od shows all forty-eight characters of the needle — while at that same moment grep finds a forty-four character prefix of it in that very file and not the whole string.

It failed in the dangerous direction. false is what the assertion read as "encrypted", so a store that encrypted nothing would have passed — and the control invented to rule that out was built from the same instrument.

What replaces it asserts what the S3 contract can state: the store takes bucket-default AES256, keeps accepting writes, and reports AES256 for the object. 824 tests pass with none skipped, against 823 and two before.

SeaweedFS skips it for a measured reason rather than a remembered one: 4.43 and 4.45 alike accept PutBucketEncryption, return the rule from GetBucketEncryption, and then fail every write to that bucket.

Images

rustfs 1.0.0-rc.4 → rc.5: the full suite is identical on either. chrislusf/seaweedfs 4.43 → 4.45: the pin had stood two versions back on a comparison confounded by the test above — ten runs showed one failure in five against three in five, that test and nothing else, p = 0.52.

Two comments that had stopped being true

• CLAUDE.md said the schema was one migration per context; seven had followed the 2026-08-28 squash.
• ci.yml said the application service has no healthcheck. The image has carried one since 2026-08-09 (d05babc) and --wait reports it Healthy. The polling stays — it asks from the host, through the published port.

Checked locally on 2026-09-07

dotnet build -c Release -warnaserror	0 warnings, 0 errors
dotnet test -c Release	824 passed, 0 skipped, 0 failed
openapi.json vs the running container	identical, sha256 79f61ee5…
development stack	up, all three services healthy
.env.example vs compose	three keys, exact both ways
.env in tree or index	none — only .env.example
Directory.Build.props, README docker pull	0.1.0