d409fe0856
For simplicity, when shellcheck returns one or more warnings, count it as a single check-package warning. The developer can get the full output either by running shellcheck directly or by calling check-package with -v. Examples: |$ ./utils/docker-run utils/check-package --include Shellcheck package/polkit/S50polkit |package/polkit/S50polkit:0: run 'shellcheck' and fix the warnings |51 lines processed |1 warnings generated |$ ./utils/docker-run utils/check-package --include Shellcheck -v package/polkit/S50polkit |package/polkit/S50polkit:0: run 'shellcheck' and fix the warnings |In package/polkit/S50polkit line 43: |< tab >start|stop|restart|reload) | ^----^ SC2221: This pattern always overrides a later one on line 45. |In package/polkit/S50polkit line 45: |< tab >reload) | ^----^ SC2222: This pattern never matches because of a previous pattern on line 43. |For more information: | https://www.shellcheck.net/wiki/SC2221 -- This pattern always overrides a l... | https://www.shellcheck.net/wiki/SC2222 -- This pattern never matches becaus... |51 lines processed |1 warnings generated NOTICE: shellcheck results depends on the version of the tool. This is why the examples above run inside the docker image. Also update .gitlab-ci.yml with the docker image after the change of the previous commit. We don't actually use shellcheck in CI, but the image from .gitlab-ci.yml is used by the docker-run script and we use that to run shellcheck. Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com> [Arnout: make sure a single -v is enough to get shellcheck output; update docker image tag in .gitlab-ci.yml] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> |
||
|---|---|---|
| .. | ||
| checkpackagelib | ||
| brmake | ||
| check-package | ||
| config | ||
| diffconfig | ||
| docker-run | ||
| genrandconfig | ||
| get-developers | ||
| getdeveloperlib.py | ||
| readme.txt | ||
| scancpan | ||
| scanpypi | ||
| size-stats-compare | ||
| test-pkg | ||
This directory contains various useful scripts and tools for working
with Buildroot. You need not add this directory in your PATH to use
any of those tools, but you may do so if you want.
brmake
a script that can be run instead of make, that prepends the date in
front of each line, redirects all of the build output to a file
("'br.log' in the current directory), and just outputs the Buildroot
messages (those lines starting with >>>) on stdout.
Do not run this script for interactive configuration (e.g. menuconfig)
or on an unconfigured directory. The output is redirected so you will see
nothing.
check-package
a script that checks the coding style of a package's Config.in and
.mk files, and also tests them for various types of typoes.
genrandconfig
a script that generates a random configuration, used by the autobuilders
(http://autobuild.buildroot.org). It selects a random toolchain from
support/config-fragments/autobuild and randomly selects packages to build.
get-developpers
a script to return the list of people interested in a specific part
of Buildroot, so they can be Cc:ed on a mail. Accepts a patch as
input, a package name or and architecture name.
scancpan
a script to create a Buildroot package by scanning a CPAN module
description.
scanpypi
a script to create a Buildroot package by scanning a PyPI package
description.
size-stats-compare
a script to compare the rootfs size between two different Buildroot
configurations. This can be used to identify the size impact of
a specific option, of a set of specific options, or of an update
to a newer Buildroot version...
test-pkg
a script that tests a specific package against a set of various
toolchains, with the goal to detect toolchain-related dependencies
(wchar, threads...)