Our own auto-updater infrastructure

[tituspijean]

I am trying to think through how we can self-host the auto-updater.

Relevant resources:

• BASH: https://github.com/YunoHost-Apps/dendrite_ynh/blob/master/.github/workflows/updater.sh
• PYTHON: https://github.com/YunoHost-Apps/wordpress_ynh/blob/testing/.github/workflows/updater.py
• Discussion on Python vs Bash, said selfhosting, and latest version of the Python scripts: Rewrite updater.sh -> .py. Remove redundant info in updater.yml. example_ynh#187
• PyGithub: https://pygithub.readthedocs.io/en/latest/
• PyGit21: https://www.pygit2.org
• Interesting SO thread on a combination of PyGithub and PyGit2: https://stackoverflow.com/questions/49458329/create-clone-and-push-to-github-repo-using-pygithub-and-pygit2

In the apps' repositories

My initial thinking:

1. Have an auto-updater.toml file to declare some variables:

   1. How we find about new versions:

      • repository (defaults to the upstream address from the manifest): commits or tags, and declare filters to exclude("RC", "beta", ...) tags (defaulting to Github, but we might include functions to handle Gitlab and other forges)
      • json, or other API

   2. Where we find the assets to download (tarball, zipball, assets from a release, other repo [looking at you, Jellyfin])

   3. How often should the auto-updater run

2. Have Salamandar's updater.py or run updater.sh with appropriate env variables to run app-specific actions. His updater_lib.py should be integrated in the core of the auto-updater

Architecture of the auto-updater

IIRC we host a copy of the repos for the catalog builder. we could tap on that, since it's updated pretty often (~4h). That would prevent us from harassing the forges API to re-download everything.

We could then crawl through all the directories reading the auto-updater.ymls, and copy the directory to a temp dir and work our magic with the scripts described above.