search

noi-techpark / sfscon-maps

c3nav navigation / maps.sfscon.it
0 stars 1 forks source link

Consider running the ``collectstatic`` command when deploying the container #7

Closed danielegobbetti closed 3 weeks ago

danielegobbetti commented 3 weeks ago

I believe it would be better to configure the pipeline to automatically run the command:

    /app/env/bin/python manage.py collectstatic -l --no-input

when deploying the container.

See for instance upstream. This command consolidates the static files (including the logo) in the static.dist path.

clezag commented 3 weeks ago

I assume this has to be run prior to starting the service? The easiest solution, but a bit hacky would be to override the entrypoint in the compose file.

I've also seen that the service can be started in, webstatic-async and web-async modes where the only difference seems to be that it calls either application or static_app here

Maybe running it as web-async already solves the issue? You can test this by setting the compose command to web-async

If not (or if there are significant performance impacts) we can do the entrypoint hack

Also maybe we could ask upstream to call this during the webstatic startup? Would make sense IMO

danielegobbetti commented 3 weeks ago

I assume this has to be run prior to starting the service? The easiest solution, but a bit hacky would be to override the entrypoint in the compose file.

Actually not, I just tested issuing the command (docker exec -it -w /app c3nav-c3nav-core-1 /app/env/bin/python manage.py collectstatic -l --no-input) and the logo appeared (it was broken after the last deploy) and this worked while the service was running. Apparently it also survives a restart of the container.

clezag commented 3 weeks ago

I've added it to the compose file, let me know if that can work. Not sure if the worker service needs it too, didn't add it there. I've tested it locally and it's startup impact is negligible.

Making it part of the CI/CD wasn't ideal either, because we'd have to lookup the specific container to run the command etc. This way at least we have everything concentrated in the compose file, it's custom anyway.

I'd just say we run with it and refactor if things turn out more complicated / difficult to maintain.