Summary
selfhostedshow/wiki has a naming conflict with an existing docker-hub image that lacks glightbox, causing inconsistent behavior between docker compose up and docker compose up --build
proposed solution
Either: Fix the image in Docker Hub.
or: define your image including a known-good container registry that is correct
or: in the compose file, replace the image: selfhostedshow/wiki with container_name: selfhostedshow-wiki to force the container to do its initial build from the Dockerfile
Background / Error message
The most recent build-and-deploy failed: https://github.com/selfhostedshow/wiki/actions/runs/13120182680/job/36604061573
The error message is
ERROR - Config value: 'plugins'. Error: The "glightbox" plugin is not installed
Aborted with 1 Configuration Errors!
2025/02/03 18:23:48 Process exited with status 1
observation
This looks really similar to #137 , where the cause was not identified but the symptoms resolved when docker compose --build was used.
local testing and analysis
If I delete the selfhosted-show-wiki docker image, then run docker compose up, I can reproduce the error (and the container refuses to start).
If I run docker compose up --build, the build succeeds and the container starts and serves the website. Stopping the container, then starting it again with docker compose up succeeds.
So there is currently a difference in behavior between when the image is simply pulled, and when the image is built. So I guess the current registered selfhostedshow/wiki:latest image (id 1ff6dbd9517f, created 4 years ago) lacks glightbox. Whereas if the user builds using the Dockerfile (which uses a different image, FROM squidfunk/mkdocs-material:latest, followed by pip install), they'll have a working build.
So the image selfhostedshow/wiki:latest (a) exists in the docker registry (unsure if that was expected at the time the Docker Compose file was written) and (b) does not have the required plugins. I think that's why users are seeing inconsistent behavior between docker compose up and docker compose up --build
Summary
selfhostedshow/wikihas a naming conflict with an existing docker-hub image that lacks glightbox, causing inconsistent behavior betweendocker compose upanddocker compose up --buildproposed solution
Either: Fix the image in Docker Hub.
or: define your image including a known-good container registry that is correct
or: in the compose file, replace the
image: selfhostedshow/wikiwithcontainer_name: selfhostedshow-wikito force the container to do its initial build from the DockerfileBackground / Error message
The most recent build-and-deploy failed: https://github.com/selfhostedshow/wiki/actions/runs/13120182680/job/36604061573
The error message is
observation
This looks really similar to #137 , where the cause was not identified but the symptoms resolved when docker compose --build was used.
local testing and analysis
If I delete the selfhosted-show-wiki docker image, then run
docker compose up, I can reproduce the error (and the container refuses to start).If I run
docker compose up --build, the build succeeds and the container starts and serves the website. Stopping the container, then starting it again withdocker compose upsucceeds.So there is currently a difference in behavior between when the image is simply pulled, and when the image is built. So I guess the current registered selfhostedshow/wiki:latest image (id 1ff6dbd9517f, created 4 years ago) lacks glightbox. Whereas if the user builds using the Dockerfile (which uses a different image,
FROM squidfunk/mkdocs-material:latest, followed bypip install), they'll have a working build.So the image selfhostedshow/wiki:latest (a) exists in the docker registry (unsure if that was expected at the time the Docker Compose file was written) and (b) does not have the required plugins. I think that's why users are seeing inconsistent behavior between
docker compose upanddocker compose up --build