Skip to content

Latest commit

 

History

History
97 lines (58 loc) · 3.66 KB

development.md

File metadata and controls

97 lines (58 loc) · 3.66 KB

Development

CVEjob runs in a container when running on a laptop. However, source code gets mounted into the container so your local code changes will be reflected when you run CVEjob via ./local-run.sh script. This makes it easy to test new changes before committing them and deploying to OpenShift.

Note you need to rebuild CVEjob Docker image when you add or update dependencies in the requirements.txt file.

To rebuild CVEjob Docker image locally, run following command:

make docker-build

Or:

make fast-docker-build

The first command will rebuild the image from scratch and the second command will only rebuild layers that have changed (it will utilize your local Docker cache).

Before doing any changes, you may want to read about CVEjob internals - how it works under the hood.

Running tests

There are unit tests in tests/ directory. Running them is easy, just type:

./run-tests.sh

QA and coding standards

  • You can use scripts run-linter.sh and check-docstyle.sh to check if the code follows PEP 8 and PEP 257 coding standards. These scripts can be run w/o any arguments:
./run-linter.sh
./check-docstyle.sh

The first script checks the indentation, line lengths, variable names, white space around operators etc. The second script checks all documentation strings - its presence and format. Please fix any warnings and errors reported by these scripts.

Code complexity measurement

The scripts measure-cyclomatic-complexity.sh and measure-maintainability-index.sh are used to measure code complexity. These scripts can be run w/o any arguments:

./measure-cyclomatic-complexity.sh
./measure-maintainability-index.sh

The first script measures cyclomatic complexity of all Python sources found in the repository. Please see this table for further explanation on how to comprehend the results.

The second script measures maintainability index of all Python sources found in the repository. Please see the following link with explanation of this measurement.

You can specify command line option --fail-on-error if you need to check and use the exit code in your workflow. In this case the script returns 0 when no failures has been found and non zero value instead.

Dead code detection

The script detect-dead-code.sh can be used to detect dead code in the repository. This script can be run w/o any arguments:

./detect-dead-code.sh

Please note that due to Python's dynamic nature, static code analyzers are likely to miss some dead code. Also, code that is only called implicitly may be reported as unused.

Because of this potential problems, only code detected with more than 90% of confidence is reported.

Common issues detection

The script detect-common-errors.sh can be used to detect common errors in the repository. This script can be run w/o any arguments:

./detect-common-errors.sh

Please note that only semantical problems are reported.

Check for scripts written in BASH

The script named check-bashscripts.sh can be used to check all BASH scripts (in fact: all files with the .sh extension) for various possible issues, incompatibilities, and caveats. This script can be run w/o any arguments:

./check-bashscripts.sh

Please see the following link for further explanation, how the ShellCheck works and which issues can be detected.