The script can be helpful outside of CI, in particular for gradually
transitioning to the new style.
Reverting commit f00201fa6c it is already possible to do something
like
$ CI_MERGE_REQUEST_PROJECT_URL=https://gitlab.gnome.org/GNOME/gnome-shell \
CI_MERGE_REQUEST_TARGET_BRANCH_NAME=master CI_COMMIT_SHA=HEAD \
.gitlab-ci/run-eslint.sh
but that is hardly convenient.
Instead, allow passing the required parameters on the command line:
$ .gitlab-ci/run-eslint.sh origin master
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/730
We aren't quite ready to enforce non-legacy style for now, mostly due
to the xgettext bug that prevents us from using template strings in
some places, and vast amounts of legacy indentation.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/716
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
