Meson stopped using polkit for automatic privilege elevation, and
will no longer attempt any priviledge elevation when not running
interactively.
Running the entire install command as root used to be problematic
in the past, as it could result in ownership changes of files in
the build directory that would result in build failures later,
but the aforementioned change leaves us with little choice.
Apparently `meson install` will spawn `ninja` with dropped
privileges when a rebuild is needed, so hopefully this will
no longer be an issue.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2892>
There is no longer a difference between regular- and legacy config.
That means that all code now follows the regular configuration, and
we no longer need a separate check that enforces this for new code.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2866>
The Config variable that was removed in the previous commit was
actually wrong (PACKAGE_VERSION vs. GETTEXT_VERSION), so the
substituation didn't work.
Meson warns about this, let's make these warnings fatal to catch
similar issues during CI.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2844>
Ever since the mutter image started to set up a non-root user for
running tests, the toolbox image built on top of it has been broken.
The issue has now been addressed, so update the image to pull in
the fix.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2850>
The eslint jobs report their results as artifacts in junit format,
so that gitlab can present them in its UI.
However many people miss that, and unsuccessfully check the logs
instead.
Account for that by also printing the results to stdout.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2829>
Toolbox is a convenient option for development, but setting up
the image with all dependencies is annoying at best, in particular
later in the cycle when `dnf builddep` is likely insufficient.
To address that, produce toolbox images for main and stable branches
that are based on the regular CI image, and update them whenever
the image version is updated. This guarantees that all build- and
runtime dependencies are included.
Unsurprisingly, the script that produces the image draws heavily
from freedesktop's ci-templates. The most notable difference
(other than being neither distro-agnostic nor generic) is that
tag names are fixed (toolbox:main, toolbox:43 etc.) to make them
easier to consume.
Instead, whether an image needs rebuilding is based on a custom
label that records the base image that was used.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2713>
Provided we use the correct version of the SpiderMonkey shell, we
can perform checks using the same engine that is used by gjs.
However some engine features are opt-in, so the set of features enabled
by gjs and js102 may differ. The obvious option for avoiding this is
replacing js102 with gjs for tests.
For that reason the check-potfiles.js script has been ported to gjs
and a second (simpler) script to replace `js102 --compileonly` was
added. This work happened in a separate repository to make sharing
between different JS-based projects easier.
Update the CI image to pull in those scripts and include gjs.
This will also address the issue that `js102 --compileonly` does not
handle modules.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2193>
Both the subdir and prepare arguments are very specific to
building the extensions-tool subproject stand-alone. In order
to make the script more generic, turn those required arguments
into optional --subdir and --prepare ones.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2712>
This test runs all of GNOME Shell using the headless backend inside a
mocked D-Bus environment. The basic test tests, well, basic things, like
the panel menu, the overview, showing the app grid view, as well as
going back to the session view.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1349>
By default, gitlab skips checking out of submodules. So far this
didn't matter to us, as meson will initialize submodules as part
of setup.
It no longer does for the dist command however, and as we run it
from a separate job where the submodule checkout isn't preserved,
the job breaks with recent meson versions.
Fix this by instructing gitlab to checkout the submodule for all
jobs that need it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2371>
Mutter and gnome-shell are released in lock-step, but I forgot to
bump the requirement accordingly.
Likewise the gsettings-desktop-schemas dependency is outdated, there
are a couple of keys we depend on that were added this cycle.
And while building should still be possible with the old gjs version,
we do require a newer version at runtime, so reflect that as well.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2183>
Besides dropping its GTK dependency (which doesn't affect us),
GWeather 4.0 replaces its own timezone type with GTimeZone.
It's easy enough to adjust to that, so port over to the new
version.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2083>
This job "needs" the build job and thus gets its artifacts, but
it will not inherit the environment where we already installed
Mutter in /usr. This apparently broke once there was a more
recent mutter-clutter .pc file to look up.
Install Mutter in /usr again in this job, so the new build for
coverity finds all dependencies.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1979>
So far, releases are done locally by invoking `meson dist`.
We can do better and leverage the existing CI infrastructure, to get
to the following release workflow:
- bump version in meson.build, update NEWS etc.
- open merge request for the release
- merge when the pipeline (including dist check) succeeds
- tag the release
- wait for the tag pipeline to spit out the tarball artifact
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1968>
GJS added a console module that extensions may start using. To ensure that
extensions using console.log() and similar functions don't show up as
'Gjs-Console' in users' system logs, we should call setConsoleLogdomain()
with 'GNOME Shell'.
This GJS API addition is only accessible using ECMAScript Modules (ESM),
this commit moves shell startup to a small init.js module and adapts
CI jobs to either handle or ignore it.
We can drop the .jscheckignore file when future versions of SpiderMonkey
allow for compile checks without validating module specifiers.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1958>
