-
Notifications
You must be signed in to change notification settings - Fork 5
CI and CD
click to see screenshots of configuration
Keeps our code clean, formatted correctly, finds any unused variables, etc.
For the developmet, we are using trunk.io to achieve a consistent coding style, keeps our code clean, formatted correctly, finds any unused variables, spell checking, and more.
You can run ./trunk fmt
to auto-format your contributions and ./trunk check
to verify your contribution complies with our standard via trunk.
We will run the same test automatically before we are able to merge the code.
If you are using Windows, be sure to run trunk fmt
through WSL terminal.
To upgrade trunk run
trunk upgrade
- black
- cspell
- markdownlint
- osv-scanner
- prettier
- ruff
- trivy
- trufflehog
documentation coming soon...
documentation coming soon...
Formatting our Python code with black
Our Trunk CI includes isort to catch any imports into our Python files that can be optimized, or if there are any unnecessary imports that are not being used within the code or any variables that are unneeded and unused.
As part of the CI checks in the trunk CI, we utilize cspell to perform spell checking. It scans our code, comments, and docstrings for spelling errors. This feature is highly valuable as it helps us catch any spelling mistakes and ensures that our documentation remains free from spelling errors (including docstrings that are converted into documentation).
within .trunk/configs/.cspell.json
is a JSON file with a list of all words we added to its dictionary and therefor ignores.
There are some places where we don't want formatting because the formatting is very sensitive and changing it can create errors or just doesn't make sense. For those places, we tell trunk to ignore that block and the specific formatter it should ignore for it
# trunk-ignore-begin(cspell)
# block of code that I want cspell to ignore and not do spelling checks on
# trunk-ignore-end(cspell)
If trunk catches any errors it will let us know within our CI, and we can easily fix it within trunk fmt
Big thanks to @InnocentBug to setting up all of the trunk CI checks and configurations for our project! 🎉
On each PR Pytest is ran to check the output of the code.
Using pytest code coverage to see how much of the code the tests cover and it will fail if it is less than the expected 90%
Using mypy to test on every push and PR to check that the types are all working and logical. It acts as one more layer of protection for our code. Only testing on ubuntu with Python 3.7 (minimum python version) and 3.11 (highest python version) to check everything works fine.
Any place that we were unsure of the correct typing or if type checking was not applicable we added # type: ignore
for mypy to ignore that part of the code. However, it is always more ideal to be able to have typings for everything within our code and not use # type: ignore
anywhere and we are striving for that!
For more, refer to wiki on Python Type Hinting
using Pytest doctest module to check that all the documentation code tests are working correctly
Tests that the documentation can be built correctly on every PR because refactoring or changing code can sometimes create issues where the documentation build fail and we never know it until we encounter the error.
CodeQL helps report any vulnerabilities within the code base to keep our code secure.
Dependency scanner checks any dependencies that we are using for any vulnerabilities, to be sure we are not introducing any vulnerabilities into the users computer through our code or any package that we are using.
Within .github/workflows/docs.yaml
is the workflow to build the documentation from docstrings within src/cript/ and MD files
then push to the built html and css to gh-pages branch.
The repository is configured to listen to the gh-pages branch for any pushes. Once there has been a push to gh-pages GitHub pages deploys deploys the new changes to the repositories GitHub pages URL. The workflow closely follows Material MKDocs documentation. Refer to documentation wiki page for more information
- Test GitHub actions locally when possible with GitHub acts package to catch syntax and logical errors
- Write GitHub workflows with VS Code GitHub actions extension to catch any syntax errors