This document details the GitHub Actions workflows used for automated repository maintenance, testing, and release management in openpilot. These workflows handle translation updates, dependency management, release builds, Docker image creation, and pull request lifecycle management. While hardware-based testing on physical devices is managed by Jenkins (see Jenkins Device Testing), GitHub Actions provides the primary CI/CD entry point for lightweight validation and repository health.
The openpilot repository utilizes several primary GitHub Actions workflows triggered by schedules, repository events (push/pull request), or manual dispatch.
Sources: .github/workflows/tests.yaml1-9 .github/workflows/ui_preview.yaml1-14 .github/workflows/repo-maintenance.yaml1-8 .github/workflows/release.yaml1-5 .github/workflows/docs.yaml1-8
The tests.yaml workflow is the primary gatekeeper for code quality. It utilizes a matrix of jobs running on both standard GitHub runners and specialized high-performance runners (e.g., namespace-profile-amd64-8x16) .github/workflows/tests.yaml28-33
| Job Name | Implementation | Purpose |
|---|---|---|
static_analysis | Calls scripts/lint/lint.sh | Runs ruff, codespell, and other linters .github/workflows/tests.yaml77-90 |
unit_tests | Runs pytest -m 'not slow' | Executes the core test suite with RAYLIB_BACKEND: headless .github/workflows/tests.yaml92-113 |
process_replay | Runs test_processes.py | Deterministic regression testing of core daemons .github/workflows/tests.yaml114-130 |
build_release | Runs build_stripped.sh | Validates that the release-ready code compiles .github/workflows/tests.yaml26-58 |
build_mac | Runs scons on macOS | Ensures cross-platform build compatibility .github/workflows/tests.yaml64-75 |
The process_replay job compares current process outputs against reference logs. If changes are detected, it uploads a diff.txt artifact .github/workflows/tests.yaml138-143 The comparison logic is executed via openpilot/selfdrive/test/process_replay/test_processes.py .github/workflows/tests.yaml130
For pushes to master, the workflow automatically updates reference data in the ci-artifacts repository's process-replay branch .github/workflows/tests.yaml152-176
Sources: .github/workflows/tests.yaml1-183
The ui_preview.yaml workflow provides visual feedback on UI changes by generating side-by-side video comparisons between the PR branch and master.
The workflow triggers on changes to UI-related paths .github/workflows/ui_preview.yaml10-13 It uses diff.py to compare recorded UI sessions for variants defined in VARIANTS, specifically mici (MiciMainLayout) and big (MainLayout) .github/workflows/ui_preview.yaml24-122 Reports are pushed to the mici-raylib-ui-reports branch of the ci-artifacts repo .github/workflows/ui_preview.yaml21-164
Sources: .github/workflows/ui_preview.yaml1-176
This workflow runs weekly to automate housekeeping tasks including package updates and car documentation.
The package_updates job performs the following:
uv lock --upgrade to refresh Python dependencies .github/workflows/repo-maintenance.yaml26git submodule update --remote .github/workflows/repo-maintenance.yaml49python openpilot/selfdrive/car/docs.py to update the supported vehicle list in docs/CARS.md .github/workflows/repo-maintenance.yaml53-54peter-evans/create-pull-request, including a uv pip tree and .venv size report .github/workflows/repo-maintenance.yaml56-78The cleanup_closed_branches job iterates through closed pull requests and deletes the associated head branch if it exists within the commaai/openpilot repository .github/workflows/repo-maintenance.yaml79-117
Sources: .github/workflows/repo-maintenance.yaml1-118
Every day at 9am UTC, the release workflow builds a "stripped" version of openpilot. It waits for CI checks to pass on master .github/workflows/release.yaml16-24 before running tools/release/build_stripped.sh with BRANCH=__nightly .github/workflows/release.yaml31 This process prepares the repository for deployment by removing development-only files.
Sources: .github/workflows/release.yaml1-32
The docs.yaml workflow manages the public documentation site at docs.comma.ai. It uses zensical to build the site from the repository .github/workflows/docs.yaml33-34 On pushes to master, it pushes the built site to the gh-pages branch of the commaai/openpilot-docs repository .github/workflows/docs.yaml37-65
This workflow identifies inactive PRs. Regular PRs are marked stale after 24 days of inactivity and closed 7 days later .github/workflows/stale.yaml9-23 Draft PRs are given more leniency, becoming stale after 30 days .github/workflows/stale.yaml10-49
Handles initial PR triage:
actions/labeler with .github/labeler.yaml to categorize changes based on paths. For example, changes in openpilot/selfdrive/car/** trigger the car label, while changes in openpilot/selfdrive/ui/** trigger the ui label .github/workflows/auto_pr_review.yaml19-22 .github/labeler.yaml5-15master. If targeted elsewhere (unless from commaai), it automatically closes the PR with a message .github/workflows/auto_pr_review.yaml25-36Manages the interface between GitHub and Jenkins. It scans comments for the trigger-jenkins phrase .github/workflows/jenkins-pr-trigger.yaml58 If a user with write access posts this phrase, the workflow creates a tmp-jenkins- branch to trigger the Jenkins HIL (Hardware-in-the-loop) pipeline .github/workflows/jenkins-pr-trigger.yaml62-85
Sources: .github/workflows/docs.yaml1-66 .github/workflows/stale.yaml1-53 .github/workflows/auto_pr_review.yaml1-36 .github/labeler.yaml1-28 .github/workflows/jenkins-pr-trigger.yaml1-97
Refresh this wiki