From bc8464ccbbaf09be0c4ee9d3c3889befad4f64bb Mon Sep 17 00:00:00 2001
From: Bart Jaskulski <bjaskulski@protonmail.com>
Date: Mon, 20 Feb 2023 10:21:51 +0100
Subject: [PATCH] fix: don't interfere with stdout/stderr in linter
`php -l` is inconsistent in it's return codes, as it may exit 0 on
correct code, but while encountering parse errors, it may end up with
0 or 255, but the message is sent do `stdout` instead of `stderr`. This
may seem irrelevant but have some serious implications.
If we decide to ignore `stdout` (which is better for readable job trace),
we may end up with error exit code but without error message, impossible
to detect. On the other hand, if we send all `stderr` output to
`/dev/null`, we consequently ignore most of errors produced by linter,
thus we think our code is valid, which may not be true.
To keep best of both worlds (succinct output and clear error messages)
rely on filtering output, to contain only those lines, which may inform
us about errors and ignore all "No syntax errors" lines as it may be the
most predictable way.
Signed-off-by: Bart Jaskulski <bjaskulski@protonmail.com>
---
includes/tests/lint.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/includes/tests/lint.yml b/includes/tests/lint.yml
index 96aac7d..80a36ad 100644
--- a/includes/tests/lint.yml
+++ b/includes/tests/lint.yml
@@ -2,7 +2,7 @@
stage: tests
script:
- composer install --no-dev
- - find -name '*.php' -print0 | xargs -n1 -0 -P16 php -l 2>/dev/null
+ - find -name '*.php' -print0 |xargs -n1 -0 -P16 php -l |grep -v "No syntax errors detected"
lint:8.1:
<<: *lint-tmpl
--
GitLab