Open LastEdit opened 5 months ago
This does not sound expected but not fully sure. Is your static folder mounted into the docker or have you placed the custom files inside of the container?
They are mounted outside by INVENTREE_EXT_VOLUME where all static media backup etc folders are found.
Have you verified that that still works? Permission wise the service in the container should not be allowed to delete mounted files
The ext volume still works and is accessible by the container. Files in my media and backup folders seem intact. I have only noticed the static folder that seems to get "reset" during the update. Also when you say the container should not be allowed to delete mounted files, I'm not sure I understand. It does delete images and templates in the media folder when they are deleted through the web front end. The only explicit variable I have set to an external volume is INVENTREE_EXT_VOLUME in .env.
This is likely because we have the --clear
flag set in collectstatic - which will be deleting any custom static files.
I guess the "fix" here would be to remove the --clear
flag - although with the new frontend (which has hashed compiled files) this will quickly lead to a lot of accumulated static files...
For the time being, I will anticipate replacing the static files after updating. Thank you for the info.
Please verify that this bug has NOT been raised before.
Describe the bug*
I completed a docker update from 0.14.5 to 0.15.1. While updating I saw a few warnings about static files that could not be found. I only recently implemented customization, so I am not sure if it is expected behavior to have to replace all custom static files after updates. Static files such as customization-options
Steps to Reproduce
Expected behaviour
Keep custom static files on update
Deployment Method
Version Information
Version Information:
InvenTree-Version: 0.15.1 Django Version: 4.2.12 Commit Hash: be3b22c Commit Date: 2024-05-15
Database: postgresql Debug-Mode: False Deployed using Docker: True Platform: Linux-5.15.0-107-generic-x86_64-with Installer: DOC
Please verify if you can reproduce this bug on the demo site.
Relevant log output