Incorporate some lint checks into `meson test`
This will make it easier and more obvious for developers to run them
locally: I'm sure I'm not the only developer who had assumed that
`.gitlab-ci/` is private to the CI environment and inappropriate (or
perhaps even destructive) to run on a developer/user system.
The lint checks are automatically skipped (with TAP SKIP syntax) if we
are not in a git checkout, or if git or the lint tool is missing. They
can also be disabled explicitly with `meson test --no-suite=lint`,
which downstream distributions will probably want to do.
By default, most lint checks are reported as an "expected failure"
(with TAP TODO syntax) rather than a hard failure, because they do not
indicate a functional problem with GLib and there is a tendency for
lint tools to introduce additional checks or become more strict over
time. Developers can override this by configuring with `-Dwerror=true`
(which also makes compiler warnings into fatal errors), or by running
the test suite like `LINT_WARNINGS_ARE_ERRORS=1 meson test --suite=lint`.
One exception to this is tests/check-missing-install-tag.py, which is
checking a functionally significant feature of our build system, and
seems like it is unlikely to have false positives: if that one fails,
it is reported as a hard failure.
run-style-check-diff.sh and run-check-todos.sh are not currently given
this treatment, because they require search-common-ancestor.sh, which
uses Gitlab-CI-specific information to find out which commits are in-scope
for checking.
Signed-off-by: Simon McVittie <smcv@collabora.com>
2024-02-07 13:16:22 +01:00
|
|
|
# Copyright 2024 Collabora Ltd.
|
|
|
|
|
# SPDX-License-Identifier: LGPL-2.1-or-later
|
|
|
|
|
|
2024-03-15 15:49:27 +01:00
|
|
|
test_env = environment()
|
|
|
|
|
test_env.set('G_TEST_SRCDIR', meson.current_source_dir())
|
|
|
|
|
test_env.set('G_TEST_BUILDDIR', meson.current_build_dir())
|
|
|
|
|
|
Incorporate some lint checks into `meson test`
This will make it easier and more obvious for developers to run them
locally: I'm sure I'm not the only developer who had assumed that
`.gitlab-ci/` is private to the CI environment and inappropriate (or
perhaps even destructive) to run on a developer/user system.
The lint checks are automatically skipped (with TAP SKIP syntax) if we
are not in a git checkout, or if git or the lint tool is missing. They
can also be disabled explicitly with `meson test --no-suite=lint`,
which downstream distributions will probably want to do.
By default, most lint checks are reported as an "expected failure"
(with TAP TODO syntax) rather than a hard failure, because they do not
indicate a functional problem with GLib and there is a tendency for
lint tools to introduce additional checks or become more strict over
time. Developers can override this by configuring with `-Dwerror=true`
(which also makes compiler warnings into fatal errors), or by running
the test suite like `LINT_WARNINGS_ARE_ERRORS=1 meson test --suite=lint`.
One exception to this is tests/check-missing-install-tag.py, which is
checking a functionally significant feature of our build system, and
seems like it is unlikely to have false positives: if that one fails,
it is reported as a hard failure.
run-style-check-diff.sh and run-check-todos.sh are not currently given
this treatment, because they require search-common-ancestor.sh, which
uses Gitlab-CI-specific information to find out which commits are in-scope
for checking.
Signed-off-by: Simon McVittie <smcv@collabora.com>
2024-02-07 13:16:22 +01:00
|
|
|
lint_scripts = [
|
|
|
|
|
'black.sh',
|
|
|
|
|
'flake8.sh',
|
|
|
|
|
'reuse.sh',
|
|
|
|
|
'shellcheck.sh',
|
|
|
|
|
]
|
|
|
|
|
|
2024-02-12 15:15:51 +01:00
|
|
|
if have_bash
|
|
|
|
|
foreach test_name : lint_scripts
|
|
|
|
|
test(
|
2024-08-27 20:25:42 +02:00
|
|
|
test_name,
|
|
|
|
|
bash,
|
|
|
|
|
args : [files(test_name)],
|
2024-03-15 15:49:27 +01:00
|
|
|
env : test_env,
|
2024-02-13 09:41:59 +01:00
|
|
|
suite : ['lint', 'no-valgrind'],
|
2024-02-12 15:15:51 +01:00
|
|
|
protocol : 'tap',
|
|
|
|
|
)
|
|
|
|
|
endforeach
|
|
|
|
|
endif
|
Incorporate some lint checks into `meson test`
This will make it easier and more obvious for developers to run them
locally: I'm sure I'm not the only developer who had assumed that
`.gitlab-ci/` is private to the CI environment and inappropriate (or
perhaps even destructive) to run on a developer/user system.
The lint checks are automatically skipped (with TAP SKIP syntax) if we
are not in a git checkout, or if git or the lint tool is missing. They
can also be disabled explicitly with `meson test --no-suite=lint`,
which downstream distributions will probably want to do.
By default, most lint checks are reported as an "expected failure"
(with TAP TODO syntax) rather than a hard failure, because they do not
indicate a functional problem with GLib and there is a tendency for
lint tools to introduce additional checks or become more strict over
time. Developers can override this by configuring with `-Dwerror=true`
(which also makes compiler warnings into fatal errors), or by running
the test suite like `LINT_WARNINGS_ARE_ERRORS=1 meson test --suite=lint`.
One exception to this is tests/check-missing-install-tag.py, which is
checking a functionally significant feature of our build system, and
seems like it is unlikely to have false positives: if that one fails,
it is reported as a hard failure.
run-style-check-diff.sh and run-check-todos.sh are not currently given
this treatment, because they require search-common-ancestor.sh, which
uses Gitlab-CI-specific information to find out which commits are in-scope
for checking.
Signed-off-by: Simon McVittie <smcv@collabora.com>
2024-02-07 13:16:22 +01:00
|
|
|
|
|
|
|
|
test(
|
|
|
|
|
'check-missing-install-tag.py',
|
|
|
|
|
python,
|
|
|
|
|
args : ['-B', files('check-missing-install-tag.py')],
|
2024-03-15 15:49:27 +01:00
|
|
|
env : test_env,
|
2024-02-26 13:08:14 +01:00
|
|
|
suite : ['lint', 'no-valgrind'],
|
Incorporate some lint checks into `meson test`
This will make it easier and more obvious for developers to run them
locally: I'm sure I'm not the only developer who had assumed that
`.gitlab-ci/` is private to the CI environment and inappropriate (or
perhaps even destructive) to run on a developer/user system.
The lint checks are automatically skipped (with TAP SKIP syntax) if we
are not in a git checkout, or if git or the lint tool is missing. They
can also be disabled explicitly with `meson test --no-suite=lint`,
which downstream distributions will probably want to do.
By default, most lint checks are reported as an "expected failure"
(with TAP TODO syntax) rather than a hard failure, because they do not
indicate a functional problem with GLib and there is a tendency for
lint tools to introduce additional checks or become more strict over
time. Developers can override this by configuring with `-Dwerror=true`
(which also makes compiler warnings into fatal errors), or by running
the test suite like `LINT_WARNINGS_ARE_ERRORS=1 meson test --suite=lint`.
One exception to this is tests/check-missing-install-tag.py, which is
checking a functionally significant feature of our build system, and
seems like it is unlikely to have false positives: if that one fails,
it is reported as a hard failure.
run-style-check-diff.sh and run-check-todos.sh are not currently given
this treatment, because they require search-common-ancestor.sh, which
uses Gitlab-CI-specific information to find out which commits are in-scope
for checking.
Signed-off-by: Simon McVittie <smcv@collabora.com>
2024-02-07 13:16:22 +01:00
|
|
|
protocol : 'tap',
|
2024-03-15 15:49:27 +01:00
|
|
|
)
|
