Skip to content

App Maintenance

Alexander Larsson edited this page Mar 25, 2019 · 7 revisions

This is a guide in how to maintain your application once it is on Flathub. It assumes your application is already on Flathub, and that you have access rights to its repository. If this is not true, please read the app submission page first.

The repository

The build information for each application on Flathub is stored in a repository on GitHub in the Flathub organization. For example, the Blender one is here: https://github.com/flathub/org.blender.Blender. On the master branch of this repository the primary build version of the app is stored. The beta branch is built into the beta repository (if you want to use that). Branches named branch/XXX are special cases used for things that have specific flatpak branch names such as extensions. Other branch names are free to use however you see fit.

Buildbot

There is a Buildbot instance running on https://flathub.org/builds, which monitors the GitHub repositories. Each time that master or beta branch changes it queues a build of the application, and if the build succeeds on all the architectures, then a test repository is generated where you can download and test the build. The build is published (i.e. signed and imported) into the Flathub Flatpak repo manually (via the web ui) or automatically after 24 hours (by default), and the build will be available to your users.

You can track your build status, follow the build log for current and historic builds, start builds or publishe build on the Buildbot instance website.

Test builds and pull requests

Buildbot also monitors the comments on any pull requests in your repository, and if they include the magic phrase bot, build (by a repo collaborator or owner) then it will start a test build. Test builds are similar to regular builds, except the results will never be publishe into the Flathub repo. You can however install the app from the test repo, where it will be available for 5 days or until you delete it.

This is a great way to do updates, you do an update locally and tests that it works. Then you can make a pull request against master to verify that it builds on all architectures before you merge it.

Limiting the set of architectures to build on.

Flathub has builders for i386, x86_64, arm and aarch64, and by default all applications build on all these. However, for various reasons your application may not work on a specific architecture. You can then create a file called flathub.json in your repository which can control this. For example, here are two samples:

Don’t build on arm:

{
  "skip-arches": ["arm"]
}

Only build on x86_64:

{
  "only-arches": ["x86_64"]
}

End of life

There may come a point where an application is no longer maintained. In order to inform users at update or install time that it will no longer get updates you can create a flathub.json file with these contents:

{
  "end-of-life": "This application is no longer maintained because..."
}

Please also try and contact a flathub admin to archive the repo by either via pinging them in issues, IRC, or emailing flathub-admins@lists.freedesktop.org

Automatic publishing delay

The default is to publish successfully built (non-test) builds after 3 hours. If you want to do this more often you can create a flathub.json file with these contents:

{
  "publish-delay-hours": 2
}

Getting Help

If anything is not working or there is some behavior you don’t understand, come to the #flatpak channel on Freenode where most of the time there are Flathub admins available that can help you.

You can’t perform that action at this time.