glib/tests/reuse.sh

92 lines
3.3 KiB
Bash
Raw Normal View History

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
#!/usr/bin/env bash
#
# Copyright 2022 Endless OS Foundation, LLC
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
#
# Original author: Philip Withnall
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
set -eu
if [ -z "${G_TEST_SRCDIR-}" ]; then
me="$(readlink -f "$0")"
G_TEST_SRCDIR="${me%/*}"
fi
skip_all () {
echo "1..0 # SKIP $*"
exit 0
}
cd "$G_TEST_SRCDIR/.."
echo "TAP version 13"
command -v git >/dev/null || skip_all "git not found"
command -v reuse >/dev/null || skip_all "reuse not found"
test -e .git || skip_all "not a git checkout"
echo "1..1"
# We need to make sure the submodules are up to date, or `reuse lint` will fail
# when it tries to run `git status` internally
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
git submodule update --init >&2
# Run `reuse lint` on the code base and see if the number of files without
# suitable copyright/licensing information has increased from a baseline
# FIXME: Eventually this script can check whether *any* files are missing
# information. But for now, lets slowly improve the baseline.
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
files_without_copyright_information_max=343
files_without_license_information_max=414
# The || true is because `reuse lint` will exit with status 1 if the project is not compliant
# FIXME: Once https://github.com/fsfe/reuse-tool/issues/512 or
# https://github.com/fsfe/reuse-tool/issues/183 land, we can check only files
# which have changed in this merge request, and confidently parse structured
# output rather than the current human-readable output.
lint_output="$(reuse lint || true)"
files_with_copyright_information="$(echo "${lint_output}" | awk '/^\* [fF]iles with copyright information: / { print $6 }')"
files_with_license_information="$(echo "${lint_output}" | awk '/^\* [fF]iles with license information: / { print $6 }')"
total_files="$(echo "${lint_output}" | awk '/^\* [fF]iles with copyright information: / { print $8 }')"
error=0
files_without_copyright_information="$(( total_files - files_with_copyright_information ))"
files_without_license_information="$(( total_files - files_with_license_information ))"
if [ "${files_without_copyright_information}" -gt "${files_without_copyright_information_max}" ] || \
[ "${files_without_license_information}" -gt "${files_without_license_information_max}" ]; then
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
echo "${lint_output}" >&2
fi
if [ "${files_without_copyright_information}" -gt "${files_without_copyright_information_max}" ]; then
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
echo "" >&2
echo "Error: New files added without REUSE-compliant copyright information" >&2
echo "Please make sure that all files added in this branch/merge request have correct copyright information" >&2
error=1
fi
if [ "${files_without_license_information}" -gt "${files_without_license_information_max}" ]; then
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
echo "" >&2
echo "Error: New files added without REUSE-compliant licensing information" >&2
echo "Please make sure that all files added in this branch/merge request have correct license information" >&2
error=1
fi
if [ "${error}" -eq "1" ]; then
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
echo "" >&2
echo "See https://reuse.software/tutorial/#step-2 for information on how to add REUSE information" >&2
echo "Also see https://gitlab.gnome.org/GNOME/glib/-/issues/1415" >&2
fi
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
if [ "${error}" -eq 0 ]; then
echo "ok 1"
exit 0
elif [ -n "${LINT_WARNINGS_ARE_ERRORS-}" ]; then
echo "not ok 1 - warnings from reuse"
exit "${error}"
else
echo "not ok 1 # TO""DO warnings from reuse"
exit 0
fi