Skip to content

CI and CD

nh916 edited this page Sep 15, 2023 · 26 revisions

Current GitHub Workflow CI/CD

Configuration

Required Checks

click to see screenshots of configuration

Main Branch

image

Develop Branch

image

Merge Queue

click to see screenshots of configuration

image

Trunk

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.

How to Upgrade

To upgrade trunk run

trunk upgrade

All Trunk Linters

  • black
  • cspell
  • markdownlint
  • osv-scanner
  • prettier
  • ruff
  • trivy
  • trufflehog

documentation coming soon...

Markdown lint

documentation coming soon...

Python Black Formatter

Formatting our Python code with black

isort

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.

cspell

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).

Configuration

within .trunk/configs/.cspell.json is a JSON file with a list of all words we added to its dictionary and therefor ignores.

Trunk Ignore

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)

Merge Queue

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! 🎉


Pytest

On each PR Pytest is ran to check the output of the code.

Pytest Code Coverage

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%

Mypy

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

Doctests

using Pytest doctest module to check that all the documentation code tests are working correctly

Documentation Build Tests

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

CodeQL helps report any vulnerabilities within the code base to keep our code secure.

Dependency Scanner

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.

Docs

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

Tips for Writing GitHub Workflow