[Discussion] Drafting a scheme to host a "Next Web Catalog" for Patches at GitHub

[Olf0]

Issue assessment

The current Web Catalog of Patches managed with Patchmanager for SailfishOS is based on the Django web-framework and must run on a "virtual server". This is co-hosted at OpenRepos.net (ORN), which runs since 2022 at Hetzner, a big German hosting provider, and is dependent on donations to pay Hetzner.

While Nephros has successfully deployed an instance for testing purposes on an own server, nobody of Patchmanager's current maintainers has experience with Django and we do not have access to the running instance: Every change has to be carried out by Coderus, from the regular mini-updates with new SFOS versions to updating Django etc. While Coderus deploys these mini-updates with due diligence and in a timely manner, single person bottlenecks are always a "bad thing"™.

Hence there is no need to rush anything, because everything worked out fine for years despite the migration of ORN in Q1/2022, but it is obvious that there is a long dependency chain, which breaks if any link of the chain breaks.

My approach

When discovering the fine granularity of access rights in a GitHub "organisation" 1,5 years ago, it immediately comes to mind to host and maintain Patches in a "Patch developers" (or "Patches for Patchmanager for SailfishOS" or something similar) organisation is with each Patch developer as a member, which implicitly grants the organisation access to their repositories (except for "private repos"). The would have to tag releases of their Patches in a specific way (e.g., every Git tag which conforms to semantic versioning: ^[0-9]+\.[0-9]+\.[0-9]+$) for them to become deployed by the "Next Web Catalog" (NWC as working title).

GitHub also provides web pages at <name>.github.io ("GitHub pages"), which may be able to contain Java Script, so we may utilise the users local computing resources. Though when researching the abilities of GitHub actions in the context of CI workflows, it became obvious which vast resources GitHub provides. GitHub actions can do much within GitHub, like reaction to a multitude of triggers (e.g., a new tag set), alter and deploy GitHub pages etc., hence my first idea was to design something based on GitHub actions. Well, if the only tool you now is a hammer, you treat everything as a nail. To avoid this effect, I started to research what else GitHub offers: "GitHub Codespaces" are unsuitable, because they do cost money and have very limited interaction outside of their virtual machine (basically only the source repository, which is mapped inside the VM), GitHub's "OAuth apps" are basically only well suited for authentication purposes via OAuth tokens, but "GitHub apps" seem to provide a superset of functionality of "GitHub actions". BTW, GitHub's webhooks seem to be solely suited for triggers to external servers.

So ultimately I see three computing resources, which can be used:

• Client side Java Script on GitHub pages.
  ^{This still has to evaluated, because GitHub's documentation seems to deal only with static pages built by Jekyll with side notes WRT other static site builders (Hugo comes to my mind as a really simple solution). OTOH GitHub's documentation states nowhere that embedded Java Script is not allowed.}
• GitHub actions
• GitHub apps (currently my "number one")

But, as a release at GitHub already automatically generates a tarball and a zip-archive of the tagged source tree, a scheme using them might require very little algorithmic logic.

_{To be continued, by me or somebody else: Just start new sections in follow up messages or criticise these sections.}

[Olf0]

Side note

BTW, we still had the GitHub "organisation" PM-developers around, which i just renamed to Patchmanager-Webcatalog2 and can be used for this purpose, in order to not interfere with the extant org's sailfishos-patches access rights ("privileges") and download volume: If we ever run into GitHub's download volume limits (although unlikely, because they are quite generously, but we also have to take scenarios like a DDoS into account, be it just for the lulz of somebody), this will not affect the development work at the org sailfishos-patches.