CI/CD

This chapter describes the CI/CD pipelines used in the project. The pipelines automate various tasks such as testing, building, and deploying.

Overview

GitHub Actions are used to manage automated workflows. Below is an overview of the key workflows included in the project:

  • Behave Pipeline: Runs behave tests and uploads the results.

  • Codecov Pipeline: Runs unit tests via pytest and uploads the test coverage. codecov-badge

  • CodeQL Pipeline: Runs CodeQL security analysis on the codebase. codeql-badge

  • Pytest Pipeline: Runs unit tests via pytest and uploads the results. pytest-badge

  • mypy Pipeline: Runs mypy checks and uploads the results. mypy-badge

  • Ruff Pipeline: Runs ruff checks and uploads the results. ruff-badge

  • ZAP Pipeline: Runs OWASP ZAP security scans on the web application. zap-badge

Sequence Diagram CI/CD Pipeline

Component Diagram CI/CD Pipeline

Composite Setup action

Since we are using uv as package manager and the setup is the same everytime, it makes sense to create a separate action that can be used from every other action. The so called “composite action” looks like the following:

As said, this action sets up the environment by installing uv via Astrals github action setup-uv and uses a pinned version, as well as caching. After this, the setup-python action is called which takes the python version from the pyproject file. At the time of writing this, that action may be faster than uv’s own action because of GitHubs caching mechanism. The action ends with maybe running database migrations depending on the switch provided by the input run_migrations.

Behave Pipeline

The following workflow file is a reusable template workflow because we want to have exactly one result for every feature file executed. That is to show the progress inside the README.md file which features are working and which do not work just yet. This workflow template uses a string as an input value which just specifies which feature file to run. First of all, we checkout the code via actions/checkout. Then, we are using the previously defined action (see Composite Setup action) to make uv usable inside this workflow. Having uv activated, the behave action is triggered for the given feature file. Note that we need to use uv run trustpoint/manage.py behave instead of uv run behave to make Django available for behave. Once the tests are ran, an artifact with the test reports is uploaded.

We provide an example on how to use this workflow below:

Codecov Pipeline

We are using Codecov for analyzing our pytest code coverage and showing this with a badge. This workflow is also setting up uv as in Composite Setup action and using it to run pytest with a coverage report which will be uploaded to codecov in the next step.

Pytest Pipeline

This pipeline/workflow is kind of the same as the one above except from not running the coverage reports and therefore also not uploading them. Here, we use a git flavored markdown report for printing the report nicely to the job summary. After this, there is the full report uploaded first and lastly, if one or more tests fail, we add a comment to the current pull request.

mypy Pipeline

We use mypy for static type checking in python. This pipeline is actually really short because it just sets up uv from Composite Setup action and then runs mypy.

Ruff Pipeline

Also, the ruff action is nearly as short as the mypy Pipeline. The only difference is that we now run ruff and upload the report if there are any errors.

CodeQL Pipeline

We use CodeQL for automated security analysis of the codebase. This pipeline runs CodeQL analysis on multiple languages including Python, JavaScript/TypeScript, and GitHub Actions. It performs static analysis to identify potential security vulnerabilities and code quality issues. The analysis is configured with a custom CodeQL configuration file and runs on a schedule as well as on pushes and pull requests to the main branch.

ZAP Pipeline

We use OWASP ZAP (Zed Attack Proxy) for automated security scanning of the web application. This pipeline performs baseline security scans on both HTTP and HTTPS endpoints of the running Trustpoint application. It starts the application using Docker Compose, runs ZAP scans on ports 80 (HTTP) and 443 (HTTPS), and uploads the scan reports as artifacts. The pipeline fails if high or medium severity issues are found, while low severity issues are reported as warnings.