Figure out how to run collectstatic in the build process

[sleepycat]

It's common for Django libraries to include static files (html/css/js/images) which then need to be "collected" into a public folder for that library to work properly.

Graphene Django does exactly this: it includes the web based GraphQL IDE GraphiQL.
Typically GraphiQL would be available at /graphql but without running manage.py collectstatic step in the build process, loading /graphql will produce a 404.

Django's build process depends on many environmental variables that might not be known at build time.

We'll need to figure out a way (or a convention) for successfully building Django apps that include these static files.

[LilaKelland]

Does PR#21/22 solve this? (added collectstatic in cloudbuild.yaml)

[Stephen-ONeil]

In CPHO, I experimented with a few approaches to this. A number of them worked, but ultimately had to make collectstatic a run-time step in the Cloud Run image's entrypoint script. I "had to" because of other constraints I'd put on myself, but I expect they'll be in place on most or all of our django apps.

The biggest constraint was that I was specifically keeping the production env file (.env.prod) out of Cloud Build. Cloud Build's logs, for public repos, are publicly viewable by default, so that's always a risk. It's also just better to keep prod secret access minimal if possible. Instead of adding .env.prod to the application image itself, I have Cloud Run mounting them to a secrets volume at run-time.

The .env.dev settings are available at build-time, and collectstatic could be run as an image build step using those, but the resulting staticfiles were not usable in production. This is probably due to the project's use of whitenoise, specifically with the STATICFILES_STORAGE="whitenoise.storage.CompressedManifestStaticFilesStorage" setting (note the Manifest portion of that string).

I didn't investigate this too deeply (the problem disappears when DEBUG = True is used 🙄 haha), stopped when I had it working, but I believe the problem is that the manifest produced with one set of env files isn't compatible with the other. Maybe we could keep collectstatic as a secret-free build-time step if we disable the manifest, but I'm inclined to think it's better to have a tiny bit more cold-start time and keep the manifests in use (I might eat those words when it's time to optimize, the cold-starts are pretty bad right now).

Note: for any project not using whitenoise, the static files need to be served from a separate CDN. We'll probably want to try and standardize on one approach or the other, because that means additional infrastructure and probably a different set of issues like this to deal with.

[Stephen-ONeil]

Closing, addressed in CPHO