This is a new gitlab feature which allows to import a file from
somewhere else with predefined config and jobs. This helps us
centralize the configuration of the flatpak jobs and keep them
in sync easily.
[1] https://docs.gitlab.com/ce/ci/yaml/README.html#include
Setting LANG and NO_AT_BRIDGE will prevent warnings about LANG not being
set (obviously) (Tracker), and about the a11y bus not being up, which we
don’t necessarily need to be able to test things.
Starting a D-Bus session before running tests ensures that dbus-launch
doesn’t croak when Tracker tries to reach the SPARQL backend, because of
missing X11 support.
Gitlab CI by default zips it's cache target which causes the files
to lose their xattributes that ostree relies upon.
This workaround makes a tarball of the cache target first, which is then
zipped by the Gitlab CI. Then on before_sciprt it extracts it in place.
Hopefully tarballs will be the default behavior in the Future™ and this
commit will get reverted.
Relevant issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/37444
Invoking `apt` triggers a warning about its interface being not stable enough for use in headless setups. That, and I messed up the last commit, so here we are.
In theory, it would be possible to just drop the GAIL code and keep the
header, but, given that NautilusCanvasItem is the only remaining
consumer, the needed bits can be moved over.
This is one of prerequisite steps to take before fully switching to GTK+
4, as gnome-desktop has code, depending on GTK+ 3. Since the
thumbnailing machinery is self-contained, it can easily be just copied
over.
It's often the case that an MR will be opened and call for testing or an artifact will be linked in an issue.
But by the time people review the changes or try to test it them, the provided bundle will be already gone.
In the early days of the gitlab migration the expiration was commonly set to a small interval to ease the transition and not eat up the resources of runners. This should no longer be required going forward and the expiration date can be more flexible.
Split the enviroment deployment from the flatpak job.
review job depends on the flatpak job, and re-exports its
artifacts for now. Then it creates a review app, that shows
a link to the flatpak bundle.
This commit also restricts enviroment deployments for the master
branch of GNOME/nautilus.
