Load admin-index fixtures in docker startup script

[alextreme]

Taken from open_zaak Dockerfile

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.10%. Comparing base (ab1950d) to head (73e2881).
Report is 23 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #1296      +/-   ##
===========================================
- Coverage    95.13%   95.10%   -0.04%     
===========================================
  Files          983      983              
  Lines        35837    35845       +8     
===========================================
- Hits         34094    34090       -4     
- Misses        1743     1755      +12     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[pi-sigma]

Can we exclude the possibility that fixtures need to be loaded in a certain order? Might not work for us even if it works for OpenZaak.

[alextreme]

Afaik this only should be necessary for django-admin-index. The other fixtures in our project have unintended consequences.

Lets create a separate dir for the fixtures to be auto-loaded, and ensure that this fixture_dir is also copied over within our Dockerfile. Copying over the Open Zaak functionality is too simple and will break things

[pi-sigma]

It seems that loading the django-admin-index fixture through Django's post-migrate signal is broken (see https://taiga.maykinmedia.nl/project/dimpact-enschede-ssc-ict-1/issue/107). Running the migrations produces the error, but manually loading the fixture immediately afterwards works (after updating the fixture, that is). I could not figure out why this started happening, so this needs further investigation.

For immediate purposes, I updated the fixture and disabled automatic loading via the signal for manual builds. I also updated the docker startup script, so we have the autoload functionality when the app is build and run with Docker.

[swrichards]

@alextreme I discussed this with @pi-sigma and we identified two reasons autoload using the post_migration hook might fail:

1. The fixture is out of date
2. Not all the contenttypes on which the fixture depends are created

Both have been fixed in #1307. Point 1 is a structural issue that recurs quite frequently: the solution here is to add a CI step that warns us when the admin-index fixture is stale. A Taiga issue has been created for this the solution was more simply: simply add a test to load the fixtures, which I've now done in #1307.

With #1307 we should have the desired behavior in both vanilla and Docker environments. Given that we don't currently auto-load any other fixtures, we decided that this PR can be abandoned for now, until we actually have >1 fixtures we want to auto-load.

Closing this, but we can re-open it if you feel differently.