docker setup seems to be embed URLs at build time

[bnjbvr]

Hi! thanks for the project. I've been wanting to use it, but I'm running into some issues when attempting to deploying it.

In particular: if I change the URLs like BACKEND_URL in the frontend section, then it doesn't have an effect immediately. For it to have an effect, it seems that I need to:

• set the raw values in the resources/config.edn file,
• rebuild the images with docker compose build manually
• restart the instances.

I would have expected that all I need is (no changes in the resources/config.edn file and only) set the environment variables, assuming they would override any default config in the resources/config.edn file. Is that not the case? Could it be I'm doing something wrong?

[bnjbvr]

It might be related to this, but I'm also running into #4 despite hardcoding the URLs for the bg helper server too.

[migalmoreno]

I would have expected that all I need is (no changes in the resources/config.edn file and only) set the environment variables, assuming they would override any default config in the resources/config.edn file. Is that not the case? Could it be I'm doing something wrong?

Yes, environment variables are meant to take precedence over the default values in resources/config.edn and in fact you shouldn't have to edit that file if all you want to do is change the backend/bg-helper URLs. However, I'm afraid I can't reproduce your issue. Using Podman, I can just do a podman compose build to builld the images with the default settings, check the FE with podman compose up, stop the services, change BACKEND_URL in docker-compose.ymlto an arbitrary value and do a podman compose build frontend followed by another podman compose up and see the changes reflected in the FE.

[migalmoreno]

It might be related to this, but I'm also running into #4 despite hardcoding the URLs for the bg helper server too.

Yes, that's entirely possible when hosting Tubo on a non-residential IP since the latest NewpipeExtractor release changed the potoken extractor client to not use the web client anymore, which Tubo currently expects. I've seen some solutions around, so I'll give it a try and fix it as soon as I can.

[migalmoreno]

@bnjbvr Can you report if this still an issue? I removed the default config bind mounts for all services in the default docker-compose.yml not too long ago which could have been causing some hiccups, if you were using that.

[bnjbvr]

Hi! just tried it again. If I changed the BACKEND_URL in the docker-compose file, then this doesn't have an immediate effect, and I needed to rebuild the frontend image, and restart it again. I'm not sure if this is the same issue as before, but it surely looks like something eerily similar.

[bnjbvr]

Also, i've ran into another issue that the updated URLs would only be taken into account in a private browser window. After playing with the non-private browser window, I've noticed that it seems the backend URL (at least this one) is stored in some kind of indexeddb, as removing the indexeddb db made it possible to get the updated backend URL on the non-private browser window, on the next reload.

[migalmoreno]

Hi! just tried it again. If I changed the BACKEND_URL in the docker-compose file, then this doesn't have an immediate effect, and I needed to rebuild the frontend image, and restart it again. I'm not sure if this is the same issue as before, but it surely looks like something eerily similar.

Tbh I'm not able to reproduce this, sorry. Does this also happen with the frontend image from Dockerhub? I've got my home instance setup with OCI containers here and I'm able to change BACKEND_URL without having to rebuild anything.

Also, i've ran into another issue that the updated URLs would only be taken into account in a private browser window. After playing with the non-private browser window, I've noticed that it seems the backend URL (at least this one) is stored in some kind of indexeddb, as removing the indexeddb db made it possible to get the updated backend URL on the non-private browser window, on the next reload.

You're right, this one I can reproduce and this is definitely what's causing it to not to have an immediate effect. What's basically happening is that on the first store load, the setting is being populated with the value from the configuration file, but on subsequent reloads, the app is grabbing the stored item over the changed item from the configuration. This is tricky because it could be the case that a user wants to change the instance URL from the settings UI and leave it that way for subsequent reloads, so I'm not sure if the configuration value should always take precedence. We could add a "Reset defaults" button in the Settings page to trigger a full settings reload (which would trigger a read of the instance URL from the configuration file), otherwise I'm not sure how to go about this.