DELIVERY: assert the new build against an old database - #24
arnelirobles wants to merge 1 commit into
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe pull request adds a ChangesSchema migration validation guidance
Priority: ⬇️ Low Estimated code review effort: 1 (Trivial) | ~5 minutes Change: Other 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
One gate, from barakoCMS today.
A Marten upgrade needed fourteen ALTER statements on the event store. The branch carried a migration for the new dependency's own tables and stated the schema story was handled. A test asserting that the schema assert command does not throw passed, because the integration fixture builds its database from the build under test, so there was no drift for it to find. The CI job that starts from an older release went red on the same commit.
That is the third time the shape has reached a branch in that repo, after a new index and a column on an existing document table. Under AutoCreate.CreateOnly the consequence each time is a host that throws on start and crash-loops with the previous container already gone.
The four em dashes the style check reports are pre-existing, in sections this branch does not touch.
Summary by CodeRabbit