Select Git revision
-
Bartek Jaskulski authored`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>
Bartek Jaskulski authored`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:
gitlab-ci-shop.yml 161 B
include:
- project: 'wpdesk/gitlab-ci'
ref: 'master'
file: '/gitlab-ci-1.2.yml'
deploy to shop:
when: on_success
deploy to demo:
when: on_success