Conversation
This commit enables auto-updates. Jackett project supports more than 500 torrent indexers and we publish releases every day. Users cannot update the Docker image daily. With this change the users can deploy any Docker image and they will get fresh updates every day automatically. It's also possible to disable updates in the Jackett UI (not recommended).
|
We usually don't like to do this because you get into situations where the whole userbase is running a different spread of containers that have updated applications internally but not system packages. We had run into that a lot with Plex in the past which we are forced into doing in contianer updating for Plex pass. There are auto container updating solutions and jackett closes cleanly on term signals afaik, is there any reason users cannot leverage something like watchtower to auto update? |
I understand, but I think that is not going to happen with Jackett because we don't have external dependencies and we don't use system libraries. If Jackett works in the current Docker image, following updates will work too. It would be interesting if users update the Docker image only when it contains changes in the base image or the libraries. I don't know what is the best solution for that. Maybe you could separate the Jackett version from the Docker image and rely on automatic updates. You can trigger the automatic update when you start the container or something. From a technical view, updating Jackett is faster and lighter than updating the entire Docker image.
Apparently not all users use an automatic update mechanism with Docker. Every day we receive issues with problems that are already fixed in the latest release. I have spent time opening this PR because we don't have enough manpower to handle all those issues caused by outdated releases. We are only 2 developers in a project with thousands of users and new releases every day. Maybe there is another solution but I can't think of anything. |
|
Still discussing this with the team , but it seems to be leaning towards doing an env flag with some guards . |
|
I agree with @thelamer I don't think it should become the default, kind of goes against all the good container principles. All our containers used to auto-update at start and we deliberately moved away from that for precisely the reasons you've highlighted, we just couldn't support a moving target. Lets see if we can find a compromise of sorts |
|
@ngosang I added the optional env var to your feature branch, keep in mind most users copy and paste the run commands so it would likely be set to true especially for novice users. |
|
I do not come to tell you how you have to maintain your software, but understand that it is very difficult for us to support thousands of people who use a Docker image that we do not maintain. The current solution is comfortable for you because issues are resolved by us. You have only 70 closed issues in this repository and we have almost 7000. https://github.com/Jackett/Jackett/issues We need all users to have the latest version of Jackett always, every day. Every day several of the 500 sites we support break (new domains, layouts, cloudflare, sites down..) and the automation tools stop working (Sonarr, Radarr, Lidarr, Potato..). If you put that together with the more than 1200 different releases we have, it is impossible for us. Disabling updates should be the exception. I can't think of any reason to disable them. If you do, Jackett stops working well in a few weeks. Also, I don't see the new environment variable as necessary. It is very easy to disable updates in the Jackett UI. The proposed solution does not work for the users that already have Jackett installed/configured. They will keep opening issues in our repository, as they always do, and we have to teach them how to change the configuration. It could take years until all of them have auto-updates. Please, propose a better solution. |
|
@ngosang I don't know enough about Jackett and C# but could you add updating to Jackett itself? Downloading the latest version and exec'ing into it or reloading relevant components? Not pretty but can work well. |
|
@ngosang how about if the env var is unset or set to true (default shown in readme) ? Let me know if that works. |
Jackett already do that but it's disabled in Docker. This RP tries to enable it.
You can rename the env var to |
|
@ngosang I'm really glad you've brought this up and are talking with us about it. Certainly not every software we make images for can be handled 100% the same, and we don't want to make extra work for you. That being said we do want to use the capabilities of docker the best we can and that includes publishing tagged image versions. Our build system keeps pace with your releases hourly. End users may not update their containers as quickly as we publish new tags/versions. That is really best resolved by encouraging users to utilize tools like watchtower. Another option I wonder if you'd be ok with is detecting if jackett is running inside a container (we can help a bit on our end by placing a file in the container indicating that the user is running in docker) and jackett could display a message in the UI if the user is out of date reminding them to update or setup a tool like watchtower to automatically update for them? Like I said, I know not every software handles updates the same, but a valid example supporting how we do things actually comes from my experience with an image we don't maintain: bitwarden_rs. They do versioning the same way we do. They published a version with a bug. I was able to roll back the docker image tag to a previous version and everything worked. The bug was reported and fixed and then I rolled up to Anyway what do you think about the UI warning for users when running out of date in docker? |
|
I have been refactoring the updater all afternoon to conclude that it's a bad solution. Jackett/Jackett#8766 First of all, I want to say that I have deep knowledge about Docker, CI, CD and version control. I know that all artifacts must have closed versions (Docker images too) to be able to reproduce issues, do rollbacks, track regressions, validate integrity... The theory is right in most cases but Jackett is not a regular software. How many software do you know that publish production releases every day?
You can keep publishing all the releases (I think is a waste of resources but I can live with that) but the users won't need to have the latest Docker image. If an accident occurs and the updater fails (In that case our problem is much bigger than yours, remember the 15.000 users without Docker). The users can download the latest Docker image manually. Ideally, you should release only new versions of the Docker image when you make changes to the Dockerfile. The tag will become outdated over time, but we can make Jackett to check for updates at the startup. If there is a problem, you can publish a version that disables updates or whatever. You are not losing all the control. Think about it. |
|
I appreciate all the data, please look at the current head of the feature branch, a person would have to go out of their way to disable the updates with the current logic . |
|
Do not merge yet, it is necessary to make a change in our part. I will be back in few days. |
|
@thelamer We are ready to merge. |
6 participants
Enable auto-updates
This commit enables auto-updates. Jackett project supports more than 500 torrent indexers and we publish releases every day. Users cannot update the Docker image daily. With this change the users can deploy any Docker image and they will get fresh updates every day automatically. It's also possible to disable updates in the Jackett UI (not recommended).
@thelamer @sparklyballs I'm a Jackett developer. This PR is well tested. You have to update the changelog and update instructions in readme.