Hi Revant!
I came up with a step-by-step instruction on how to replicate the problem.
It doesn’t even install any other custom app other than the frappe app itself and also omits the frontend, scheduler and queue containers.
I hope this minimal example can help others to replicate the behavior.
Preparation:
git clone https://github.com/frappe/frappe_docker
cd frappe_docker
Configure demo custom image:
(I’m running on macOS, so just using base64 instead of base64 -w 0)
export APPS_JSON='[]'
export APPS_JSON_BASE64=$(echo ${APPS_JSON} | base64)
Build demo custom image:
docker build \
--build-arg=FRAPPE_PATH=https://github.com/frappe/frappe \
--build-arg=FRAPPE_BRANCH=version-14 \
--build-arg=PYTHON_VERSION=3.10.12 \
--build-arg=NODE_VERSION=16.20.1 \
--build-arg=APPS_JSON_BASE64=$APPS_JSON_BASE64 \
--no-cache \
--tag=frappe-custom:latest \
--file=images/custom/Containerfile .
Create a minimal compose.yaml based on the one used in frappe_docker. We omit the frontend image and the other backend images as we don’t need them to reproduce the issue:
nano compose-demo.yaml
Insert file content:
x-customizable-image: &customizable_image
# By default the image used only contains the `frappe` and `erpnext` apps.
# See https://github.com/frappe/frappe_docker/blob/main/docs/custom-apps.md
# about using custom images.
image: frappe-custom:latest
x-depends-on-configurator: &depends_on_configurator
depends_on:
configurator:
condition: service_completed_successfully
x-backend-defaults: &backend_defaults
<<: [*depends_on_configurator, *customizable_image]
volumes:
- sites:/home/frappe/frappe-bench/sites
services:
configurator:
<<: *backend_defaults
entrypoint:
- bash
- -c
command:
- >
ls -1 apps > sites/apps.txt;
environment:
SOCKETIO_PORT: 9000
depends_on: {}
backend:
<<: *backend_defaults
volumes:
sites:
Deploy the docker-compose stack:
docker compose -f composer-demo.yaml up
Verify in new terminal window that assets filename and filename referenced in asset.json match:
(In new terminal window)
[Host] docker exec -it frappe_docker-backend-1 bash # you possibly have to modify the container name
[In Container] ls -la sites/assets/frappe/dist/css | grep website.bundle # Note filename of the asset css file
[In Container] tail -n5 sites/assets/assets.json # Note filename of the file referenced in assets.json
[In Container] exit
Up until this point, the two filenames are identical and the application would work as expected (if we had a frontend container etc. running).
In my case, the filename in both cases is:
website.bundle.WFSQXEFO.css
(We only compare this one file for brevity, the issue is the same for all asset files)
Now, we build a new version of the image and redeploy the stack
docker build \
--build-arg=FRAPPE_PATH=https://github.com/frappe/frappe \
--build-arg=FRAPPE_BRANCH=version-14 \
--build-arg=PYTHON_VERSION=3.10.12 \
--build-arg=NODE_VERSION=16.20.1 \
--build-arg=APPS_JSON_BASE64=$APPS_JSON_BASE64 \
--no-cache \
--tag=frappe-custom:latest \
--file=images/custom/Containerfile .
(Edit: Add --no-cache to make sure the image is not cached when building again without any changes)
Optional: Verify the new image is part of our local docker image list using
docker image ls and looking at the “created” column.
Redeploy the docker-compose stack
(note how the terminal window where we deployed the stack the first time is still open, and docker compose is still running there! We don’t stop the stack, we just deploy an update):
docker compose -f composer-demo.yaml up
Leave the terminal and command running and open a third console window to verify the assets.json file:
[Host] docker exec -it frappe_docker-backend-1 bash # you possibly have to modify the container name
[In Container] ls -la sites/assets/frappe/dist/css | grep website.bundle # Note filename of the asset css file
[In Container] tail -n5 sites/assets/assets.json # Note filename of the file referenced in assets.json
[In Container] exit
(Edit: One all-in-one command to check the asset file hashes)
docker exec -it frappe_docker-backend-1 bash -c 'ls -la sites/assets/frappe/dist/css | grep website.bundle && tail -n5 sites/assets/assets.json | grep website.bundle'
Note how the filename of the assets files and the ones referenced in assets.json now deviate. In my case, the output is as follows:
frappe@2f7e2d6fd893:~/frappe-bench$ ls -la sites/assets/frappe/dist/css | grep website.bundle
-rw-r--r-- 1 frappe frappe 424294 Jun 26 13:21 website.bundle.TYF3V5B2.css
-rw-r--r-- 1 frappe frappe 644921 Jun 26 13:21 website.bundle.TYF3V5B2.css.map
frappe@2f7e2d6fd893:~/frappe-bench$ tail -n5 sites/assets/assets.json
"print_format.bundle.css": "/assets/frappe/dist/css/print_format.bundle.G2J7LXX4.css",
"report.bundle.css": "/assets/frappe/dist/css/report.bundle.QOWEEDD3.css",
"web_form.bundle.css": "/assets/frappe/dist/css/web_form.bundle.S4ZINDVU.css",
"website.bundle.css": "/assets/frappe/dist/css/website.bundle.WFSQXEFO.css"
}frappe@2f7e2d6fd893:~/frappe-bench$
The actual built css file is named differently in the new container build, but the asset.json still references the old filename.
When we were running a frontend and the other containers, we could see that when opening the application with a web browser, the assets would fail to load. (404)