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
Mutter's CI now also builds gnome-shell to ensure that a MR doesn't
break the shell. Its docker image has therefore been updated to contain
all our deps as well, so we don't need our own image anymore.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/546
Running dnf to update and install additional packages every time
the job is executed slows down the CI pipeline. Avoid this by
using another custom images for JS source checks.
In addition to the js shell we use for the existing syntax check,
also include eslint for future jobs and some extension-specific
tooling to make the image more useful to extension authors.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/408
So far we are only performing a basic syntax check on javascript
sources; it's time to test the C code as well. As mutter is tightly
coupled, we bite the bullet and build it as well, either using a
matching branch (if it exists), or current master.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/408
This adds a pipeline stage for merge requests that checks that the
commit message contains an URL to either a issue or a merge request.
This means that for merge requests without corresponding issues will
always fail initially, as the merge request URL is not known until after
it is created. This is still arguably better than accidentally merging
merge requests without URLs.
Taken from https://gitlab.gnome.org/GNOME/mutter/merge_requests/440.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/410
Building gnome-shell is tricky due to the tight coupling with mutter,
but until we figure out the best way forward, we can at least perform
some basic syntax checking on the javascript bits.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/367
