xfdesktop will be needing it soon.

Soon this will be needed by libxfce4windowing.

And some other packages needed by apps/catfish!60.

I had originally used a log file in !101 because clang-format-diff <= 17
didn't emit an error code in the event of non-empty output, but this is
no longer the case with clang-format-diff >=18, so the use of this file
is no longer justified.

Amends: cbbceb2fa207a56a74abf77d14054b76a201ba03

i.e. for commits on default branch and merge requests against default
branch. Do not run these jobs for tags, it's pretty useless and would
force us to distinguish between tags on default branch and tags on
maintenance branches.

Do not run these jobs on translation commits either, since in this case
the build jobs didn't run (unfortunately 'needs' doesn't handle this
automatically).

Amends: 8bf2175d178313c2b6b6a7efb634cd98917c2290

Otherwise, it's possible for a pattern to correspond to several
warnings, not all of which are false positives. By adding sufficiently
precise patterns as indicated in the comments, this is unlikely, but not
impossible.

In the case of this pattern, for example, currently present in
xfce4-panel:
tasklist-widget.c:[0-9]+:[0-9]+: warning: dereference of NULL 'child' \[CWE-476\] \[-Wanalyzer-null-dereference\]
the 'child' variable has enough occurrences in the tasklist-widget.c
file that the risk of a multiple match cannot be ruled out.

The simplest way to specify a multiple match seems to be to add the
pattern several times, instead of specifying the number of matches,
which would require additional parsing with a delimiter.

Amends: 8bf2175d178313c2b6b6a7efb634cd98917c2290

This may be necessary in certain situations, for example when performing
static analysis with scan-build, to ensure that the standard C++ library
is added to the linker. See
panel-plugins/xfce4-sensors-plugin#48 (comment 90769)

Otherwise it overrides CC and uses the default compiler, i.e. gcc in our
case, making build-clang a duplicate of build-gcc + scan-build.

Fixes: 8bf2175d178313c2b6b6a7efb634cd98917c2290

This requires extra effort on the part of maintainers, and is therefore
disabled by default. To activate these jobs, you need to add the CI/CD
variables GCC_ANALYZER and/or SCAN_BUILD to each project.

These static analysis tools are quite prone to false positives, so for
these jobs to be useful, it seems the right approach is to not allow
them to fail and maintain false positive files (otherwise we risk
getting used to seeing them fail and simply not paying attention). How
to fill in these files is indicated in the comments.

As we only change software versions every two years in CI, the extra
maintenance effort should be quite small though, once the first warnings
have been fixed or ignored. The fact remains, however, that their
analysis can be more tortuous and time-consuming than that of simple
compiler warnings.

Also, the list of warnings not to be turned into errors for the gcc
analyzer will need to be updated every time we change version, i.e.
again every two years (otherwise the build-gcc job is likely to fail
when checking the compiler during configuration).

Closes: #51

Jobs and inheritances are starting to pile up, so it's best to give
things a name that won't cause confusion.

In addition to the --enable-debug=werror (i.e. full + -Werror) of the
build stage, so we should compile all code paths (relative to debug
mode). This requires projects not to use DISTCHECK_CONFIGURE_FLAGS
directly in their Makefile.am, but AM_DISTCHECK_CONFIGURE_FLAGS, so that
the flags we set here are not overwritten.

This is the default behavior that seems to have been overwritten for no
good reason. Typically distcheck should not run if build has failed.

This is a corner case, but it can happen when a sequence of commits
results in an empty diff (for example, a commit followed by a revert).

Fixes: cbbceb2f

For parole and xfce4-screensaver, to be removed when these issues are
solved:
apps/parole#114
apps/xfce4-screensaver#153

Instead of adding them to each project, and thus having them as correct
.build extensions. This remains opt-in, with projects wishing to
activate these builds having to define (X11|WAYLAND)_FEATURE CI/CD
variables. I had originally thought of parsing configure.ac to detect
this, but it doesn't seem to be supported; maybe that's better.

Including on glib deprecation warnings, which are probably the only ones
we care about.

This assumes that XDT_FEATURE_DEBUG is used on all projects where
build_project.yml is included, which is currently the case.

This only applies to the build stage, as other distcheck-specific
warnings may appear that we don't necessarily want to turn into errors,
especially on vala projects. Also, this leaves open the possibility of
applying another debug level to distcheck, and thus compiling other code
paths.

By default, projects are configured so that a running pipeline is
interrupted if new changes are pushed in a merge request. But for this
to work in practice, all jobs in the pipeline must also be flagged
interruptible, otherwise the pipeline is not interrupted.

See https://docs.gitlab.com/ee/ci/yaml/index.html#workflowauto_cancelon_new_commit

Related: apps/orage#32

- More recent version of everything, should help to introduce new
  features.
- Bump docker dind (docker-in-docker) image used to build CI container
  itself

Probably a regression introduced in 2759f19c.

Fixes: #62

For xfce4-weather-plugin.

Related: panel-plugins/xfce4-weather-plugin!26

This is only useful for components packaged in flatpak in practice, i.e.
for Mousepad and Ristretto. There's no point in asking to update this
file if it's irrelevant.

Hopefully this will prevent releasing without changing the version
number.

For xfce4-indicator-plugin.

We use C99 features in various places (especially init-statement in for
loops), and C99 allows declaration after statement. This also avoids
warnings from other projects, like GObject Introspection >= 1.76.1 via
g-ir-scanner.

For gettext migration of project containing a policykit file.