Support uploading Flatpak bundles to GitHub pages

[PhrozenByte]

Instead of relying on the 3rd-party tool nightly.link to reference the Flatpak bundles created and stored as artifact by Flatter, it would be great if we could alternatively upload them directly to GitHub Pages.

This could be a great addition to #91

[andyholmes]

I'm not sure there's much benefit to this, to be honest.

The Flatpak bundles are built from the repository, so uploading them there is generally redundant. A .flatpakref file basically serves the same purpose, by referring to an application in the repository directly.

The bundle option itself is generally meant for pull requests, so that apps can be tested before merging into the default branch.

[PhrozenByte]

I absolutely agree that a .flatpakref file (#91) should be the preferred way of installing a Flatpak.

However, there are still use cases for Flatpak bundles, like keeping an archive of old versions, or distributing Flatpaks to systems without internet access (even though Flatpak bundles notably don't include dependencies and extra data some applications require), or distributing specially crafted / modified versions of a software not intended to be published. Thus, it might be a good idea to make adding Flatpak bundles to the website optional and off by default. However, for users that do want to publish Flatpak bundles, GitHub artifacts are no real alternative due to the default 90 days retention policy.

Just to note, personally I'm not sure whether I'd still upload the Flatpak bundles after #91 was implemented; probably not. I just wanted to share the suggestion, it's definitely no must-have and adding such option would just make things way easier for users that do want to upload Flatpak bundles.

[andyholmes]

However, for users that do want to publish Flatpak bundles, GitHub artifacts are no real alternative due to the default 90 days retention policy.

Well, you're welcome to deploy those elsewhere after the artifacts have been built and uploaded. The nightly.link app just allows linking to them directly.

#91 is pretty difficult to implement, unfortunately, without either:

1. Making a lot of assumptions about where the Flatpaks will end up, and somehow using appstream to get data from the repo about the applications.
2. Adding about a dozen inputs, so that each .flatpakref can have it's metadata pre-defined (excluding GPG keys, etc)

1 kind of defeats the purpose of custom setup, and 2 is really one line short of doing it by hand (which is what I do).

I'm not opposed, but to be honest I don't have plans to add many features here that don't come as contributions, seeing as how my personal use-case is fulfilled.

[PhrozenByte]

I'm not opposed, but to be honest I don't have plans to add many features here that don't come as contributions, seeing as how my personal use-case is fulfilled.

I can absolutely relate to that, so no hard feeling at all, just thanks for what you've created here ❤️

1 kind of defeats the purpose of custom setup, and 2 is really one line short of doing it by hand (which is what I do).

Hmm... Yeah, I thought something like that, because .flatpakref files are way more common than Flatpak bundles and I figured that you'd have added it already otherwise. Too bad.

Can you provide an example on how to create a .flatpakref file by hand? Because that's indeed the only thing I'd say is truly missing right now. If Flatter can't help much with creating a .flatpakref file anyway, there isn't much of a point to implement it; just an example on how to do it manually would be very much appreciated. I'll add it to my workflow then. Thanks 👍