This document aims to provide a accessible yet comprehensive overview of the liboqs CI setup.
liboqs relies on GitHub Actions for almost all of its CI and makes extensive use of reusable workflows.
All workflow files are located in the .github/workflows
subdirectory.
These workflows are triggered by GitHub events (for example, a pull request or a release). They implement the logic dictating which tests should run on which events.
This workflow is triggered by pushes to non-main
branches.
It calls only basic checks unless one of the following strings is included in the commit message:
- "[full tests]": calls all platform tests.
- "[extended tests]": calls the extended tests.
- "[trigger downstream]": calls the downstream release tests.
To trigger multiple test suites, include multiple trigger strings in the commit message. For example, "[full tests] [trigger downstream]" will trigger both the platform tests and the downstream release tests.
This workflow runs on pull requests. It calls basic checks, platform tests and scorecard analysis.
This workflow runs on pushes to the main
branch (typically done automatically when a pull request is merged).
It calls platform tests, scorecard analysis, and basic downstream tests.
This workflow is triggered by a weekly schedule. It calls extended tests and scorecard analysis.
This workflow is triggered when a release (including a pre-release) is published on GitHub. It calls extended tests and downstream release tests.
These workflows are not triggered directly by any GitHub event. They are instead called by one of the caller workflows. Users with "write" permissions can also trigger them manually via the GitHub web UI or REST API.
This workflow runs a minimal set of tests that should pass before heavier tests are triggered.
These workflows contain tests for the individual platforms supported by liboqs. Currently, these include
android.yml
,apple.yml
,macos.yml
,linux.yml
,windows.yml
, andzephyr.yml
.
All of these these are wrapped by platforms.yml
.
This workflow calls all of the platform-specific tests.
This workflow calls tests which are either resource intensive or rarely need to be triggered. Currently, this includes constant-time testing with valgrind and the full suite of NIST Known Answer Tests.
This workflow triggers basic CI for a selection of projects that depend on liboqs
.
Currently, these include
Callers must include secrets: inherit
in order for the appropriate access tokens to be passed to this workflow.
This workflow triggers release tests for a selection of projects that depend on liboqs
.
Currently, this is only the OQS OpenSSL3 provider
.
Callers must include secrets: inherit
in order for the appropriate access tokens to be passed to this workflow.
This workflow runs the OpenSSF scorecard tool.
It is additionally triggered automatically when branch protection rules are changed.
Callers must include secrets: inherit
in order for the appropriate access tokens to be passed to this workflow.
In the past, we used Travis CI to test on some IBM platforms that are not supported by GitHub Actions. Our Travis builds are currently disabled pending resolution of issue #1888.