Now that we fixed all pre-existing errors that are common between
regular and legacy configuration, we can stop filtering the result
by the lines modified by the merge request.
This will allow us to catch errors in merge requests that slipped
through until now, for example when leaving a newly-unused import
behind.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/716
The eslint wrapper script is useful for development as well, but it currently
fails on systems where bash is not installed in /usr/bin.
Make it useful there as well by changing the shebang to use /usr/bin/env
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/655
When a MR uses a private namespace, "origin" refers to that, and its
master branch may be outdated with regard to upstream master.
We are really only interested in checking the line changes from the commits
in the MR, so figure out the correct branch point instead.
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
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
Depending on how gitlab's CI checks out gnome-shell, the shell branch
may not have a local reference like "gnome-3-32", but only a remote
one like "remotes/origin/gnome-3-32".
Consider that case as well when looking for a corresponding mutter branch.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/511
If we don't find a branch that matches the branch used in the merge
request, we currently fall back to the non-merge-request matching,
i.e. first try the current shell branch, then fall back to master.
This should work for commits to upstream branches, but not for merge
requests to a stable branch. For those, the target branch name is
a better fallback.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/509
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
