Run tests with ninja test with a xvfb-run mocked display inside a Flatpak environment. The mocked display has a resolution of 1024x768.
Flatpak bundle for every MR and commit
The main goal is to create Flatpak bundles so people can install and run them.
Create a Flatpak package/bundle and export it
Create a GitLab artifact to save the generated bundle for 14 days
Use a caching mechanism to reduce build times
To achieve all that, we will extend the previous CI file. The result will be exposed in the MR. Good thing is that is already handled by the template. The bundles will be created for all builds, but exposed only in the MR gui.
The template will create a Flatpak bundle with flatpak build-bundle and the runtime pointing to the value of RUNTIME_REPO variable. Once the build is done you will see a widget that exposes the artifacts of the job in the MR and that can download the generated Flatpak bundle.
Flatpak builds on every commit to master
The nightly builds can be published to GNOME Nightly Flatpak Repository, by adding the following job. It will publish the build on the master branch, but only if it is marked as protected in gitlab.
nightly:extends:'.publish_nightly'# assuming your job in named 'flatpak'dependencies:['flatpak']
Saving build and test logs & cache builds
If the CI fails, we need a way to retrieve the logs. For this we use the artifacts tool of GitLab too. The provided template exports the meson-logs.txt and the testlog.txt files as part of the artifacts.
Final gitlab-yaml file template
Here is the resulting template, but it is recommended to try doing it step-by-step.
include:'https://gitlab.gnome.org/GNOME/citemplates/raw/master/flatpak/flatpak_ci_initiative.yml'flatpak:image:'registry.gitlab.gnome.org/gnome/gnome-runtime-images/gnome:master'variables:MANIFEST_PATH:"build-aux/flatpak/org.gnome.NautilusDevel.yml"MESON_ARGS:"-Dprofile=Devel"FLATPAK_MODULE:"nautilus"APP_ID:"org.gnome.NautilusDevel"RUNTIME_REPO:"https://nightly.gnome.org/gnome-nightly.flatpakrepo"BUNDLE:"nautilus-dev.flatpak"extends:.flatpaknightly:extends:'.publish_nightly'# assuming your job in named 'flatpak'dependencies:['flatpak']
For GLib & Gtk+ based apps we need to generate a different dbus id, so different versions can be installed and ran alongside. For that, we created the concept of "profiles" in the building phase. This is a bit tricky and also needs to be done all at once for the major part.
The stable profile will be used for distributions and stable versions, and the development profile will use a different id for the application itself, the icons, the installation path, services, etc.
First, let's add basic support for profiles in the root meson.build file.
ifget_option('profile')=='Devel'name_suffix=' (Development Snapshot)'elifget_option('profile')!=''profile=get_option('profile')name_suffix=get_option('profile')elseprofile=''name_suffix=''endif# Replace AppName with your app nameapplication_id='org.gnome.AppName@0@'.format(profile)# We will use this inside the actual code to give visual hints that# it's a development versionconf.set_quoted('PROFILE',profile)# Used to put in the about dialog the git commit that was used to buildconfig_h=declare_dependency(sources:vcs_tag(command:['git','rev-parse','--short','HEAD'],fallback:get_option('profile')!='default'?'devel':'stable',input:configure_file(output:'config.h.in',configuration:conf),output:'config.h'))
And make sure to add the config_h dependency to your project dependencies. Usually in the executable command:
Lastly, add a meson option in the meson_options.txt file for the profile:
If you are providing a Nightly variant of your application icon, make sure to name it "org.gnome.AppNameDevel.svg" (replace "AppName" by your application name). This way the code above will assign the desired icon to each profile.
Desktop file handling
The desktop file name has to match the dbus id, so we need to recreate it based on the profile selected.
For that, in the data/meson.build create the desktop file with:
The goal is that the person installing a profile knows that it's a development version right away, including in case errors are reported with an screenshot. For that we will add an style to the app when running in devel mode.
This almost does what we would want, but not quite. If you build this way it will always try to fetch your modules from the source specified in the manifest, but we want to use our local checkout instead. This is fine if you only build the master branch but MRs need to be able to change the source to their checkout.
To achieve this we use the --stop-at=module argument which will build all of the dependencies up to your module from the manifest. Then we take over and need to install the application ourselves. This is why your config
s CONFIGURE_ARGS variable needs to be kept in sync with your module's config options in the manifest.
A previous version of the template had some extra review and stop_review jobs, what happened to those?
They have been deprecated and replaced by a simpler feature that provides the same function. It should simplifies both the template setup, and the backend setup needed to run the previous jobs. For more you can refer to this commit