fix: commit 46 missing api/authorization migrations, gitignored for a long time - #167
Merged
Merged
Conversation
Blocked the production deploy's release step: `search_index --populate` crashed with `relation "publication" does not exist`. Root cause traced much further than expected. .gitignore had `api/migrations/*` and `authorization/migrations/*` -- every migration generated for either app since whenever that was added has been silently invisible to git, no matter how many times someone ran `git add`. This repo's `api/migrations/` only ever had `0001_initial.py` committed (likely force-added once, or predates the ignore rule); `authorization/migrations/` had nothing at all, not even `__init__.py`. Confirmed via git log this wasn't always broken: `30480c6 "reset migrations"` deliberately squashed history down to one clean `0001_initial.py` at some point (a legitimate, intentional cleanup, probably around a Postgres migration). But nothing was ever committed again afterward -- every migration generated since (via normal `makemigrations` + `git add`, silently swallowed by the ignore rule) only ever existed on whichever host it was generated on. dev-cds's live checkout had the full, real, working set: 46 files for `api` (0002-0047, ending in the Publication/ResourceType migration this deploy needed) and all 5 for `authorization` (0001-0004 + __init__.py, defining `authorization.User` itself -- AUTH_USER_MODEL). Pulled all 51 files directly from dev-cds (read-only), verified: - Every file compiles clean (`py_compile`). - The full api dependency chain is linear and unbroken, 0001 -> 0047, no gaps, no branches. - authorization's 4 files chain cleanly from 0001, which itself correctly depends on api/0023 (a real cross-app FK relationship) -- confirms the two apps' histories are genuinely interleaved and consistent, not independently drifted. - No overlap with the deliberately-excluded fetch_resource_data feature from the earlier dev/main reconciliation (PR #153) -- the two incidental substring matches found were unrelated migration filenames. Removed both ignore rules. Django migrations must always be committed; there is no legitimate reason to exclude them. This also means any genuinely fresh database (a new contributor's local setup, a CI job with --create-db, a disaster-recovery rebuild) has been silently unable to reach current schema this whole time -- would have stopped dead at whatever 0001_initial.py defines. That risk is now closed.
saqibmanan
added a commit
that referenced
this pull request
Sep 11, 2026
…ration-dev fix: commit missing migrations (dev companion to #167)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why — much bigger than it first looked
Blocked the production deploy's release step: `search_index --populate` crashed with `relation "publication" does not exist`.
Tracing it back: `.gitignore` had `api/migrations/` and `authorization/migrations/`. Every migration generated for either app since whenever that was added has been silently invisible to git — `api/migrations/` only ever had `0001_initial.py` committed, `authorization/migrations/` had nothing, not even `init.py`.
Confirmed via `git log` this wasn't always broken: `30480c6 "reset migrations"` deliberately squashed history to one clean `0001_initial.py` at some point — a real, intentional cleanup. But nothing was ever committed again afterward. Every migration since (generated normally via `makemigrations` + `git add`, silently swallowed by the ignore rule) only ever existed on whichever host it was generated on. dev-cds's live checkout had the full, real, working set.
What this PR does
Pulled all 51 missing files directly from dev-cds (read-only), verified:
Removed both ignore rules — Django migrations must always be committed.
The bigger implication
Any genuinely fresh database (a new contributor's local setup, a CI job with `--create-db`, a disaster-recovery rebuild) has been silently unable to reach the current schema this whole time — it would stop dead at whatever `0001_initial.py` defines. That risk is now closed.
Test plan