Rework Bad Tags: Sonarr/Radarr/etc. & Download Clients for hardlinks ++ Drop unsupported gchr.io

[bakerboy448]

• Current composes are poor paths which result in duplicate space for all seeding torrents and IO abusive copy+delete imports see https://trash-guides.info/hardlinks/

• also Prowlarr should not be using nightly, it should be on develop - https://github.com/caprover/one-click-apps/blob/master/public/v4/apps/prowlarr.yml

General:

• for *Arrs hotio containers are preferred over lsio, but lsio is acceptable
• hotio updates quicker, builds *Arr PRs (except Sonarr) which are useful for testing from time to time, and does not provide the optional non-hardlink compliant mounts that LSIO does
• if you choose not to change the mounts then at least stay in sync with upstream and make them optional
• neither hotio nor lsio are publishing to gchr.io anymore and thus users will have forever out of date - and eventually unsupported - containers
• tags should not be hardcoded to random versions; but rather latest or the otherwise most stable tagged branch should be used (i.e. if no latest, but has develop then use develop)
• • https://github.com/caprover/one-click-apps/blob/master/public/v4/apps/radarr.yml#L20 versions should not be hardcoded, why are users starting on an unsupported out of date Radarr version?
• https://github.com/caprover/one-click-apps/blob/master/public/v4/apps/sonarr.yml#L20 - preview has been end of life and not supported for over 8 months
• https://github.com/caprover/one-click-apps/blob/master/public/v4/apps/qbittorrent.yml#L22 - current versions are v14; these are comically out of date

[githubsaturn]

One click apps are generally community maintained. Feel free to test the most recent version and open a PR.

tags should not be hardcoded to random versions; but rather latest or the otherwise most stable tagged branch should be used (i.e. if no latest, but has develop then use develop)

No. Tags are intentionally locked to a particular version to avoid breaking changes. Contributors are expected to test the tag that they are pushing to this repository to make sure it works. Future versions might have different requirements and might break the build.

[bakerboy448]

all latest versions of the *arrs are stable and have been stable for many months, but if ya'll wish to not maintain the apps - relying on the community to - and publish versions that are explicitly end of life (i.e. sonarr's preview tag) and not supported or containers that no longer are updated as the build pipieline changed so be it I guess

Future versions might have different requirements and might break the build.

this doesn't make sense at all - how can a new container of automation apps or download clients break the build?

docker containers - by definition - keep all requirements and dependencies within themselves

[githubsaturn]

this doesn't make sense at all - how can a new container of automation apps or download clients break the build?

A future version might require a new env var.

One click app repository is fully extensible. You don't need to rely on this repository. If you're confident that your usage of latest won't break the functionality, you're more than welcome to spin up your own collection of one click apps, the process is extremely straightforward and many folks are already using this: https://github.com/caprover/one-click-apps#build-your-own-one-click-app-repository