How gnome flatpaks for applications are built

Build System

The GNOME build system builds applications from the gnome-apps-nightly Git repository. This contains an .app file for every app that gets built. These typically look something like:

ID=org.gnome.Photos
JSON=flatpak/org.gnome.Photos-unstable.json
GITURL=git://git.gnome.org/gnome-photos
GITBRANCH=master

This describes the:

• Application ID
• URL and the branch to the repository containing the flatpak JSON manifest
• Path to the manifest in the Git repository.

Each of these files are considered to be owned by the individual apps, so feel free to commit updates for your apps as you wish.

Stable and Master

The build system builds two git branches from the gnome-apps-nightly repository: master and stable. master gets built into the gnome-apps-nightly flatpak repo and is meant to be an unstable nightly build against an unstable runtime. stable is meant to be the latest stable version built against official releases and a stable runtime.

The stable applications tend to be built against release tarballs (as these are the official releases, and because the sha256 source checksums provide some protection against network attacks against the build system) and the unstable ones are typically built against git master. However, nothing prohibits you from using git sources in the stable builds too. But if you do, please point it to specific commits or tags, not branches that change over time (so that builds are reproducible).

JSON Manifests

It is up to each maintainer how to store the JSON and the related files, but Alex recommends a model where you use two JSON files:

1. org.the.App-unstable.json - uses git repos and is always kept up-to-date

2. org.the.App-stable.json - kept up-to-date in the current stable branch

The advantage of a setup like that is that during the time of a release you may not have a stable branch separate from the master branch, and if you have two files, then you can make the stable one point to the new tarballs without affecting the unstable one (or risk the unstable one being built as stable).

Release Process

In a two-file setup like the above a release of (say 3.24) would be:

1. Tag the release and release tarballs
2. Edit the stable json in master to point to the tarballs
3. When satisfied, edit the stable branch of gnome-apps-nightly to point to the master branch (was gnome-3-22 before)
4. At some point, create a stable gnome-3-24 git branch
5. Update stable gnome-apps-nightly to point to gnome-3-24 branch
6. Update json in stable branch each time you make a release

Both the stable and the unstable application branches are built once a day and whenever the .json file changes, on i386, x86-64, arm and aarch64 build servers. The builds from the unstable applications and runtimes are automatically published on sdk.gnome.org within a day. However, the stable releases need to be signed and published, which is currently handled by AlexanderLarsson. He does this somewhat regularly, but if you need it sooner, send a mail.

The intel build machine results are available at sdkbuilder1.gnome.org which has build logs as well as repostories for stable and unstable builds which you can use to test the builds before they get published.