I was curious if anyone has any advice on the following:

I have a home server that is always accessed by my main computer for various reasons. I would love to make it so that my locally hosted Gitea could run actions to build local forks of certain applications, and then, on success, trigger Flatpak to build my local fork(s) of certain programs once a month and host those applications (for local use only) on my home server for other computers on my home network to install. I’m thinking mostly like development branches of certain applications, experimental applications, and miscellaneous GUI applications that I’ve made but infrequently update and want a runnable instance available in case I redo it.

Anybody have any advice or ideas on how to achieve this? Is there a way to make a flatpak repository via a docker image that tries to build certain flatpak repositories on request via a local network? Additionally, if that isn’t a known thing, does anyone have any experience hosting flatpak repositories on a local-network server? Or is there a good reason to not do this?

  • jrgd@lemm.ee
    2·
    7 days ago

    The flatpak documentation has a semi-relevant page on setting up a flatpak repo utilizing gitlab pages and gitlab’s CI runners on a pipeline. Obviously, you’d need to substitute Gitlab Pages for a webserver of your choice and to port the CI logic over to Gitea Actions (ensuring your Gitea instance is setup for it).

    A flatpak repo itself is little more than a web server with a related GPG key for checking the signatures of assembled packages. The docs recommend setting up the CI pipeline to run less on-commit to the package repos and more on the lines of checking for available updates on interval, though I imagine other scenarios in a fully-controlled environment such as a selfhosted one might offer some flexibility.

    • MoogleMaestroOPEnglish
      1·
      7 days ago

      Yeah, thanks for sharing this. I’m going to have to give this a try sometime.

      I had previously been building it manually, but I think I’m starting to realize that gitlab/github CI is basically essential to running a proper repository anyway.