Changes in Flathub land

The last month or so we’ve been working in the background on a major update to the Flathub infrastructure. This has been available for testing for a while, but this week we finally enabled it on the live system. There are some pretty cool internal changes, including a new repo manager microservice written in rust. Later blog posts will talk about some of the technical details, but for now I’ll just talk about the user visible changes.

Power to the maintainers!

Flathub uses buildbot to to manage the builds, and we have updated and customized the UI a bit to be nicer for maintainers. For example, we now have a page listing all the apps ever built, with links to per-app pages showing builds of that app.

We also integrated GitHub authentication so that maintainers of individual applications automatically have authority to do operations on their own apps and builds. For example, the home and per-app pages have buttons that let you start builds, which anyone with write permissions to the corresponding GitHub repository can use. Also, similarly they can cancel or retry the builds of their own apps. Previously you had to ask a Flathub administrator to restart or cancel a build, but no more!

New publish workflow

There has also been a major change in the workflow for builds. It used to be the case that a successful build was immediately imported into the repository and was then available to users. Now instead, a successful build is available for installation in a test-repository. The build system will display a link to it so that you can easily install and test the build results. When you’re satisfied that the build is ok you can then manually push a button to export it to the public repository.

If you don’t manually publish the build, then it will be automatically published, by default after 24 hours, but this is configurable by the app maintainer. See the wiki for details.

Testing the test builds

Test builds used to only verify that the app built, but with the new system they get built into test repositories just like regular builds. This means you can actually install and test the builds, for example from a pull request against your application. Such test repos stay around for 5 days, or until you explicitly delete then in the build web UI.

Test builds are also more useful now due to the permission work, as developers can easily create or cancel them from the web ui, or by using the “bot, build” command in a GitHub issue, without needing help from the Flathub admins.

Also, test builds started from a GitHub issue gets nice comments pointing to the test build and the build result. Here is an example of a pull request with automatically built tests showing how this looks.

We now automatically queue test builds for all new PRs, although such builds are less prioritized than regular builds (for resource reasons) and can take a while to start.

Publish beta releases!

In addition to the existing stable repository Flathub added a repository for beta builds. Exactly if and how this is used is up to each individual application maintainer, but the goal of this is to have a way for developers to get early releases of new stable versions into the hand of regular users.

This isn’t meant to be used for nightly builds, but for releases that has some level of testing and are expected to mostly work and be usable to non-developer end-users.

The way this works is that each GitHub repository builds the master branch for the stable repository, which will have the flatpak branch name “stable”, and then the beta git branch will build into the beta repository with the flatpak branch “beta”.

As a user, the beta channel looks like a separate remote. First you configure it as a remote:

$ flatpak remote-add flathub-beta

And then you can install any apps from it:

$ flatpak install --user flathub-beta org.godotengine.Godot

Alternatively, you can use a flatpakref, which are generated for each app:

$ flatpak install

The above Godot example is the latest beta of Godot 3.1, whereas the stable repo still contains 3.0. You can see how this beta build is set up in GitHub.

If you install both the beta and the stable version of an app then they will be installed in parallel. However, only one will be showed in the menus. You can switch which one is currently showed like this:

$ flatpak make-current org.godotengine.Godot [beta|stable]

But from the command line you can always start any installed version explicitly, like this:

$ flatpak run --branch=beta org.godotengine.Godot
$ flatpak run org.godotengine.Godot//beta

Now, go build some betas!

8 thoughts on “Changes in Flathub land”

  1. regarding beta-testing: is flatpak capable of creating crash-reports automatically (+support for separate debuginfo)?

  2. Hi,
    I’m a huge fan of flatpaks.

    1. Is possible to run to multiple versions of the same app at the same time (beta and stable or current and 1.x)?
    2. Any plans to add functionality to lock a version of an app to avoid accidental updating?
    3. Any plans to add a web site/gui/something to ease the creation of flatpak manifest files/appdata.xml? Many of the people I work with struggle to create working manifest files. Things are typically corrected in the PR request to flathub but others don’t even get there. They struggle and decide to quit instead.
    4. Snap seems to be more popular. Any plans to create a simple converter (snapcraft.yml to flatpak manifest) to help get more applications using flatpak?

    1. 1. Yes
      2. No planned atm, but seems like a useful feature
      3. Packaging is programming, its fundamentally complex, a ui doesn’t really make it easier
      4. Packaging is not robustly “convertible” like this. You can’t just auto-convert a debian package to a fedora rpm. For example, snap depends on ubuntu core, which is a version of the ubuntu distribution, which is no available in a flatpak. Instead you’d have e.g. the kde or gnome runtimse which probably has mostly similar packages but is not quite the same.

  3. Nice changes. Probably not meant as a tutorial but the adding of flathub-beta as “a user” is missing “–user” if you truly meant it that way.

    Also, when you try to do this with no pre-existing installation you’ll need to install the runtime.

    Again, you probably didn’t mean this as an all inclusive tutorial but incase someone else tries with less experience.

  4. Thanks for the instructions! I couldn’t find any good information for how to install beta Flatpaks anywhere on the web, and ended up here.

    Running 3.1 rc2, much appreciated!

Leave a Reply to alexl Cancel reply

Your email address will not be published. Required fields are marked *