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 two 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 using a GitLab feature called Review Apps. Good thing is that is already handled by the template and we just need to add a "review" stage for using the Review Apps feature.
The bundles will be created for all MRs, which means all branches that do not contain "gnome-*" in their names and also it won't be created for the master branch.
The template will create a Flatpak bundle with flatpak build-bundle and the runtime pointing to the value of RUNTIME_REPO variable. Once the deploy is done you will see a play button in the MR that will download the generated Flatpak bundle.
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.
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:
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.