This job does:
1. Download the coverity bundle and untar it in a cached location
2. Build GNOME Shell using clang and the coverity tool
3. Compress the coverity report
4. Upload for analysis
In a similar setup to that of Mutter.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1913>
It was on one hand using multi-line piping (`|`) and trying to
compensate with \ to escape multiple lines, this lead to:
No match for argument: \
Also, the quoting around pkgconfig() arguments would lead to
double quoting at the shell level, thus:
No match for argument: 'pkgconfig(gio-2.0)'
Fix both by using multi-line-turns-single-line piping (`>`)
and dropping the unnecessary quotes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1913>
This ports over gnome-shell and the theme test case to MetaContext,
instead of the various functions that were available before.
The test case is changed to use the special test context, used to
construct contexts for testing. It's part of a shared libary separate
from the main libmutter one.
This enables building mutter tests during CI, as the test framework is
needed by some of gnome-shell's tests.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1840>
This bumps both the mutter image to the F34 one, as well as the one used
for review.
This also bumps ci-templates hashes, so that we can use
FDO_DISTRIBUTION_PACKAGES without installing weak dependencies.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1906>
only/except keywords where deperecated in favor of rules.
Since we started using GNOME/gnome-shell!1492 it introduced
a second pipeline being run for each commit.
Detached pipelines are the only way to access CI_MERGE_REQUEST_*
variables, and if we disable normal pipelines you will need to
create wip/spam MRs in order to run the tests.
This reworked rules makes it so, the normal pipeline needs manual
interaction to be started, and the detached/MR pipleines is always
run.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1503>
The image registry must be enabled for the CI to work, as the container
image from the upstream registry is placed (as a reference, more or
less) in the local registry.
Recently, ci-templates got a bit more helpful if this happened, and will
fail up front and generate a JUnit report with a message describing the
issue.
Update to this version.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1505>
This rebuilds the automaticaly whenever the image tag changes. Whenever
something in the image needs to change, alter the installation script
and change the tag to the current date.
This removes the -s (strict) argument from js68, as it doesn't exist in
js78.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1492>
We have been transitioning to the new coding style for a while now,
and there has been reasonable progress. So hopefully it is not too
intrusive at this point to enforce non-legacy style for all lines
that are changed in a merge request. If it turns out to be still too
annoying, we can always reconsider and turn off the additional job.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1497
This is unnecessary hard in shell when compared to a proper programming
language. It becomes even easier with a node-js script, as that gives us
access to the underlying ESLint module rather than just the CLI interface.
Besides that, node-js has the added benefit that we don't need to add
more dependencies to the CI image.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1497
A recent Docker image update broke the test, as xgettext now prints
the following warning:
warning: a fallback ITS rule file '/usr/share/gettext-0.21/its/metainfo.its'
is used; it may not be in sync with the upstream
That is completely unrelated to what the test is meant to catch and
could be fixed by adding appstream to the image, but considering that
- the test didn't actually catch the last template string regression
- we no longer allow template strings in files that include translatable
strings (and enforce that with a CI job)
- as of gettext 0.20.2, the template handling really really is fixed
(we'll see)
let's remove the test rather than piling up more stuff in the container
image.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1399
The template has been updated to rewrite the manifest to use the
checked out tree, so it's no longer necessary to pass additional
build arguments (which are now ignored) or generate translations
before the build (it's already in the manifest).
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1217
Sadly, xgettext's dealing with template strings is abysimal, so we
had to stop using them in files with translatable strings.
Make sure we don't accidentally sneak in template strings again(*)
and enforce that rule in a CI job.
(*) easy "mistake", considering how much nicer they are than
String.prototype.format()
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1016
Also known as "Piotr Drąg Bot".
We will soon make sure that files processed by xgettext don't use template
strings. To make that check as adequate as possible, ensure that no source
code files are missing from POTFILES.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1016
Something changed recently in the test initialization code, causing
the test-theme invocation to fail. Make sure there is a D-Bus session
by running the tests through dbus-run-session to get them going again.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/796
The check is supposed to run for all merge requests that touch javascript
files, but for some reason I see it's skipped quite often. Better have
the test run unnecessarily some times than let bugs through, so remove
the limitation.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/647
We have now reduced the number of eslint errors enough to add it to
the CI pipeline. There are still plenty of errors left though, so we
cannot simply run eslint and fail on any errors. So instead, run it
through a fancy script that:
- generates an eslint report using the "regular" configuration
- generates an eslint report using the "legacy" configuration
- creates a combined report with errors common to both configurations
When the pipeline is running for a branch or tag, the final report is
printed out and the job succeeds (we know there are errors left);
when the pipelne is running for a merge request, we fail if any errors
are reported for the lines modified/added by the MR.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/627
GNOME apps use 'review' for the CI stage that generates and exports a
flatpak bundle after a successful build, so they need some other name
for anything that is checked before building; that's how we ended up
with the somewhat awkward 'source_check' stage (inherited from Polari).
But since the commit log check added a 'review' stage that runs pre-build,
use that for all checks that are performed before the build stage.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/627
