Skip to content

Continuous integration

Continuous Integration (CI) is provided by both GitHub and GitLab. It can be used to make sure that code that is committed is automatically tested and that it can be built, potentially on a matrix of architectures and operating systems.

Running example — automated checks. The temperature analysis uses the same command locally and in CI: python3 -m unittest discover -s docs/running_example/reference_implementation -p 'test_*.py'. The workflow demonstrates the benefit of applying the agreed software and scientific checks after changes; participants are not expected to construct a CI pipeline in this training.

You can find an example of using CI for development in the repository CI-example. A workflow is defined that will run on a push or a pull request to both main and development. If that workflow fails, the pull request can not be merged. The workflow will run pytest and mypy to perform unit tests and static type analysis respectively. This can be a safeguard against accidentally merging commits that break your code. This also relies on the configuration of the main branch that requires the build to succeed in order to allow a merge.

The same repository also illustrates how poetry can be used to manage Python development projects.

Automated review on pull requests

A pull request provides a well-defined, version-controlled difference that can be reviewed by people and by automated services. For example, an AI-assisted review can be requested automatically when a pull request is opened and can comment on possible defects or improvements.

This is related to CI, but the roles differ:

  • automated code review interprets the change and suggests issues that merit attention;
  • continuous integration executes the project's declared builds, tests, static checks, and other repeatable checks; and
  • human review evaluates intent, design trade-offs, scientific assumptions, and whether the available evidence is sufficient.

Use automated review as another source of feedback, not as proof of correctness or a replacement for human approval and scientifically meaningful tests. The dated agentic software-development tools page includes GitHub Copilot code review and the current configuration points to verify.

You can also use CI to build your documentation using doxygen, mkdocs or other tools such as, e.g., Sphinx. The documentation can be automatically deployed using GitHub Pages thanks to predefined actions. In fact, these web pages are rendered and published using mkdocs and a GitHub workflow. This workflow will check out the main branch, render the site using mkdocs in the gh-pages branch so that it is published. Each time a push is done to the main branch the workflow is run, and the latest version is guaranteed to be available via GitHub Pages. You can find the workflow definition in the .github/workflows directory in the repository.

Since this is in fact a deployment of documentation, it is referred to as Continuous Deployment (CD). It would of course also be possible to typeset a LaTeX document in a workflow, and make a PDF version available for download.