Commit Graph

16 Commits

Author SHA1 Message Date
Florian Müllner
1aca2ba6bb ci: Disallow legacy style in merge requests
In order to transition from the current legacy style to the modern
gjs one, use the MR line-filtering we used to do on common errors
to ensure new code complies with the new style.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/716
2019-09-12 23:18:27 +02:00
Florian Müllner
e9131465dd ci: Fail on any common lint errors
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
2019-09-12 23:18:27 +02:00
Marco Trevisan (Treviño)
108ac7cf20 ci: Make eslint wrapper script usable outside gitlab's CI
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
2019-07-31 23:28:43 +02:00
Florian Müllner
1b7ff76092 ci: Fix identifying commits in MR
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
2019-07-25 22:31:31 +02:00
Florian Müllner
3b5d13a0b2 ci: Add eslint job to review stage
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
2019-07-24 00:35:25 +02:00
Florian Müllner
8ea6fd1925 ci: Include git in extension-ci image
It's useful for anything that does not want to limit itself to the
checked out branch, like comparing source and target branch.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/627
2019-07-24 00:28:45 +02:00
Florian Müllner
6d4b9d29b8 ci: Switch to mutter's docker image
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
2019-05-17 20:52:44 +02:00
Florian Müllner
ab9710ee7b ci: Improve script output
git-fetch's -q flag doesn't suppress warnings, so it's not a full
replacement of the redirection that was removed in commit 8cefd919.
Shut up the cryptic warning and replace it with a clearer log message
instead.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/511
2019-04-26 21:32:51 +02:00
Florian Müllner
43cef45229 ci: Try harder to find a matching mutter branch
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
2019-04-26 21:32:51 +02:00
Florian Müllner
8db4f3c67f ci: Handle merge requests for non-master branches
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
2019-04-26 21:32:51 +02:00
Florian Müllner
594a070029 ci: Fix checking out mutter for stable branches
Remote branches always start with the remote itself, so just looking
for "gnome-3-32" etc. won't produce a match.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/509
2019-04-26 21:32:51 +02:00
Florian Müllner
c2e04e3cfa ci: Silence some warnings
... as suggested by Jonas in mutter!548.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/509
2019-04-26 21:32:51 +02:00
Florian Müllner
72be8eeb31 ci: Use custom image for JS checks
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
2019-02-26 21:08:17 +00:00
Florian Müllner
2d4989e937 ci: Add build stage
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
2019-02-26 21:08:17 +00:00
Florian Müllner
d671eb1969 ci: Sync check-commit-log script with mutter
A couple of cleanups came out from the review in mutter, catch
up with those.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/408
2019-02-26 21:08:17 +00:00
Jonas Ådahl
27d0d9f2b3 gitlab-ci.yml: Add check for issue or MR URL
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
2019-02-13 20:41:02 +01:00