A docker image containing several prepackaged linters to simplify code analysis.
7.4K
A docker image containing several prepackaged linters to simplify code analysis. Only run lint-it command into your current directory and check the results.
lint-it is able to analyze following languages:
More precisely following linters are prepackaged into the image:
git clone [email protected]:Heraclez/lint-it.git
cd lint-it
docker build -t lint-it:latest .
export LINT_IT_VERSION=0.9.0
docker pull dsoguet/lint-it:$LINT_IT_VERSION
To simplify image use, add following alias to your ~/.bashrc file
export LINT_IT_VERSION=0.9.0
mkdir -p ${HOME}/.lint-it/cache
alias lint-it='docker run --rm \
-v ${PWD}:/home/lint-it/code \
-v ${HOME}/.lint-it/cache:/home/lint-it/cache \
-e USER_ID=$UID \
dsoguet/lint-it:$LINT_IT_VERSION \
python3 /opt/lint-it/lint_it.py --check-update-at-start'
Then source ~/.bashrc file
source ~/.bashrc
Simply run following command to get a feedback from linters about the code present into your current directory
lint-it
By default the script analyses the code available into the container at location /home/lint-it/code. That's why the mount point of lint-it alias above is -v ${PWD}:/home/lint-it/code.
So simply run following command to obtain a feedback from the linters about your code.
lint-it
Another mount point of lint-it alias above is -v ${HOME}/.lint-it/cache:/home/lint-it/cache.
It activates a cache directory for Trivy linter. Trivy will store into this directory its CVE
database and will avoid to download it at each run.
Exit status is 0 if no issue is detected by linters, else 1.
If you need to retrieve linters feedbacks into output files, for example for Jenkins analysis, following command can be run
lint-it --cicd
In this case the mount point <HOST_DATA_DIR>:/home/lint-it/data must be used to retrieve those output files, i.e. that alias above can be written as follows (you need to change <HOST_DATA_DIR> according to your setup):
alias lint-it='docker run --rm \
-v ${PWD}:/home/lint-it/code \
-v ${HOME}/.lint-it/cache:/home/lint-it/cache \
-v <HOST_DATA_DIR>:/home/lint-it/data \
-e USER_ID=$UID \
lint-it:$LINT_IT_VERSION \
python3 /opt/lint-it/lint_it.py --check-update-at-start'
A .lint-it.ini configuration file can be set at project root directory. The different functions available with this configuration file will be detailed in following sections.
A common behavior for all those parameters, is that a [DEFAULT] section can be used to give the same parameter value to all linters.
If for some parameters the linters must not have the same behavior, then dedicated ini section can be added for them. More precisely following sections can be added:
In some cases, could be interesting that lint-it ignores some files. Typically project's test files.
For this purpose a .lint-it.ini file at project root directory, and the parameter exclude can
be used.
Typically to ignore all files into tests directory following .lint-it.ini file can be used:
[DEFAULT]
exclude = \./tests/.*
To ignore the file .gitlab-ci.yml, the second level of files into tests directory and the directory tmp following .lint-it.ini file can be used:
[DEFAULT]
exclude = \./tests/[^/]*/.*
\./\.gitlab-ci.yml
\./tmp/.*
The following .lint-it.ini file by default ignores test directory, but for yamllint linter ignores also tmp directory:
[DEFAULT]
exclude = \./tests/.*
[yamllint]
exclude = \./tests/.*
\./tmp/.*
File/directory paths must be relative to the project, and the syntax allowed is the one of python regexp.
In some cases, could be interesting that lint-it analyses some files, but does not return code 1 even if some warns are raised.
For this purpose a .lint-it.ini file at project root directory, and the parameter return_code_ignored can
be used.
Typically to always obtain the return code 0, and in the same time see all the linters warnings, following .lint-it.ini file can be used:
[DEFAULT]
return_code_ignored = true
To always obtain the return code 0 for trivy linter, and obtain the return code 1 for other linters if a warning is raised, following .lint-it.ini file can be used:
[DEFAULT]
return_code_ignored = false
[trivy]
return_code_ignored = true
If nothing is specified, by default lint-it considers by default that return_code_ignored = false.
true and false are the two possible values for this parameter.
By default all linters are enabled. But if for example you know that no python code is available in your
project, then you can disable python linters with the parameter enable. For example deactivation of
python linters can be performed with following .lint-it.ini file :
[bandit]
enable = false
[flake8]
enable = false
[pylint]
enable = false
Run following command to obtain more information about the usage of lint_it script
lint-it -h
To easily detects if new versions of linters are available, start the container as follows :
docker run --rm -e USER_ID=$UID dsoguet/lint-it:$LINT_IT_VERSION list_updatable_linters.sh
Add a -h to obtain more information about this script.
Commit logs must follow Conventional Commits format which is based on the Angular convention i.e. commit message must be structured as follows
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
Following types are managed by the configuration file .gitchangelog.rc present into the project:
Based on this convention gitchangelog is used to generate CHANGELOG.md The current configuration file defines to gitchangelog how to parse git logs to generate the CHANGELOG.md For remind CHANGELOG.md content can be obtained with such command
gitchangelog <LAST TAG>..
Note that release and wip type is not displayed into the CHANGELOG
export LINT_IT_NEW_VERSION=X.Y.Z with a correct X.Y.Z version./bin/release.sh ${LINT_IT_NEW_VERSION}Lint-it is licensed under the GNU General Public License v3. A copy of this license is included in the file LICENSE.
Content type
Image
Digest
Size
395.5 MB
Last updated
over 4 years ago
docker pull dsoguet/lint-it