Docker image not using packaged webui #989
Comments
|
This is intentional, somewhat, but that may be a little bit of a side effect of the changes a while back we changed the file path to be in the user directory, but what will happen is if there is no installed webui it will copy the pre-packaged version across to the user directory @da3dsoul do you think we should try and add some smarts for checking if there is a build update and force it if webui has an updated version? |
|
I am also more than happy to help with the Linux and docker side of things. With Docker, it's purpose is to provide a controlled and replicatable environment. If portions are being updated out from under you, there is potential for breakage and ruins the repeatable aspect that docker provides. At the moment if I were to pull an old docker image, some packages will be queued for updating and the latest WebUI will be retrieved. If anything major changed with the newly downloaded packages, or even the WebUI's api, then the image itself would be unusable. |
I would actually propose for there to be a way to opt-out of an automatic update. That way the application itself can update whatever it pleases, as well as allowing a docker image to choose not to by default and use what it already has. That way, old images can be repeatable and less prone to breakage. This would then help fulfill the philosophy that containers shouldn't update their binaries. Instead if one would like to update to the latest version, they can do so by pulling the current image available on their own time. |
|
The problem is also maintaining compatibility with windows and the few that have outside-of-docker installs. I understand the major goal around the container architecture, it is somewhat why I actually choose to use it when creating the Linux build (and convinced the rest after a while) The reason I came up with that initial solution is that would allow for the case where a user upgraded webui manually to another version, but the build-time packaged version is older it’ll keep that |
|
I would say no. It has an auto installer (you click a button on first run), but downloading things without asking is generally frowned upon |
|
If I might also add, I feel it may be possible to introduce something so that other installs and variables wouldn't be impacted. It may require some additional configuration values, but could be doable. For example, I noticed a check is performed to see which OS is running. Once Linux is detected, we could also check for a configuration value or environment variable that is explicitly placed when an image is built with the Dockerfile. We could then use this information to not download the newest WebUI from the repository, and point the WebUI path to the existing one already contained in the docker image. |
|
I do think it would be reasonable to put the latest stable WebUI in the docker container on build. |
It's already there but it's copied to |
|
The latest is already being installed when the image is build. The issue is that it is never referenced or used from what I can tell |
while yes, extra conditional logic makes it a pain with user configuration, debugging and maintenance, generally speaking we have been moving away from needing it
that has been done since the initial version of the dockerfile |
@Cazzar thoughts? Anybody using a custom webui build can use a volume if they like EDIT: Like I do |
I feel this would help with debugging too, since you can control the server's version and environment, while also hotswapping an experimental build of the WebUI by mounting to |
Personally, I’d prefer to keep it consistent between OSes, as mentioned it makes it a pain for debugging/documentation |
that’s already achievable with the current docker file |
|
With the current setup, there is just the issue where the WebUI is located in One workaround for now would be to symlink the directory |
what do you mean? |
|
I think they mean with the differences between Windows and Linux mainly, since paths can vary a lot more. There's also some behaviors that would be desirable if you were to install the shoko server directly on a Linux system instead of using a container. |
Even without trying to avoid the initial update, if the docker image always symlinks before the server is ran, then it won't try to update since something exists already. The main issue I think you would come across is if you mount a custom webui. You would just have to mount to |
|
#990 is just a proposal I have that would avoid having to change and maintain new configuration values. This also would not interfere with Windows or plain Linux installs which is a plus. |
|
Just for reference, I have been working on something else, but what seems to be the best idea, is adding a new settings configuration that will allow setting the folder where the webui is formed from, and allowing it to be set to |
PLEASE READ BEFORE POSTING YOUR ISSUE
Please create GitHub issues only for bugs and feature requests. If you need help with using Shoko or have a question, join us on Discord.
https://discord.gg/vpeHDsg
===== Guidelines ====
VERSION INFORMATION
Server Version: Docker Daily
Desktop Version: N/A
If you've compiled your own version, please use the last commit you compiled.
LOG FILE
N/A
DESCRIPTION
I have been using the Docker images that you guys provide for quite some time. It works great for my needs and I love it. I recently noticed that the WebUI was having a lot of breakage for me, and since I regularly update my docker image I was curious if something upstream broke something. After some time investigating, I noticed that the WebUI was not using the latest version that was packaged which is located at
/usr/src/app/build/webui. Instead, the server will point to '/home/shoko/.shoko/Shoko.CLI/webui' or download the latest version there if not present. Now if you follow the Docker installation for Shoko, a volume would be mounted from the host into '/home/shoko/.shoko/Shoko.CLI/' so that server databases and configurations will be persistent. Now since I had been using this setup for a few versions, the WebUI was never being updated ever since I first set it up which left an aging version of the WebUI in this mounted volume and would be used instead of the updated version that came with the docker image.While you can work around this by toggling a WebUI update manually, this would be undesirable since the philosophy behind docker is that it has everything it already needs up front, and if anything needs to be updated, a new docker image should be built and used instead rather than modifying the current image.
STEPS TO REPRODUCE
docker exec <SHOKO_CONTAINER_NAME> cat /usr/src/app/build/webui/version.jsonand verify the listed version differs from what your browser is using.The text was updated successfully, but these errors were encountered: