This document covers the continuous integration, continuous deployment, and distribution systems for the OpenBB Platform. It explains the GitHub Actions workflows that enforce code quality, validate contributions, run automated tests, draft releases, and publish packages to PyPI. For information about local development setup and quality tools, see Development Setup. For details on code quality tools and testing frameworks, see Code Quality and Testing.
The OpenBB Platform uses GitHub Actions to automate the entire pipeline from pull request validation through package distribution. The CI/CD system ensures code quality, runs comprehensive test suites, manages release notes, and publishes packages to both Test PyPI and production PyPI with nightly builds for continuous access to latest features.
Sources: .github/workflows/README.md1-101
The platform enforces GitFlow naming conventions for all pull requests through the Branch Name Check workflow. This workflow validates branch names before merging to ensure consistency across the codebase.
| Branch Type | Pattern | Target Branch | Example |
|---|---|---|---|
| Feature | feature/<name> | develop | feature/add-historical-data |
| Bugfix | bugfix/<name> | develop | bugfix/fix-date-parsing |
| Hotfix | hotfix/<name> | main | hotfix/critical-api-fix |
| Release | release/<version> | main | release/3.2.0 or release/3.2.0rc1 |
The workflow extracts branch names using jq and validates them against regular expressions:
develop: accepts feature/*, bugfix/*, and hotfix/*main: accepts only hotfix/* and release/*If validation fails, the workflow exits with status code 1, blocking the merge.
Sources: .github/workflows/README.md9-32
The platform automatically labels pull requests based on file paths and branch names using the labeler workflow. This categorization helps with release note generation and issue tracking.
| Label | Trigger Condition |
|---|---|
platform | Files match openbb_platform/.* |
v4 | Files match openbb_platform/.* |
enhancement | Branch matches ^feature/.* |
bug | Branch matches ^hotfix/.* or ^bugfix/.* |
excel | Files match website/content/excel/.* |
breaking_change | Files match openbb_platform/core/openbb_core/provider/standard_models/.* |
The appendOnly: true setting prevents removal of manually added labels.
Sources: .github/labeler.yml1-28
The CI/CD system runs three tiers of tests for pull requests:
The testing workflows activate on:
opened, synchronize, editedfeature/*, hotfix/*, release/*Each workflow uses Python 3.10 and GitHub Actions caching to improve performance.
Sources: .github/workflows/README.md65-100
The platform uses Release Drafter to automatically generate and categorize release notes from pull requests. Two configurations exist: a general release drafter and a platform-specific drafter.
The release drafter generates versions using the template OpenBB Platform v$NEXT_MINOR_VERSION and categorizes changes based on PR labels:
| Category | Labels | Description |
|---|---|---|
| 🚨 Breaking Changes | breaking_change | Changes to standard models |
| 🦋 Platform Enhancements | platform, v4 | New features and improvements |
| 🐛 Bug Fixes | bug | Bug fixes |
| 📚 Documentation | docs | Documentation updates |
The configuration template includes:
$CONTRIBUTORS)$CHANGES)- $TITLE @$AUTHOR (#$NUMBER)
Core team members are excluded from the contributors list to highlight community contributions:
Sources: .github/release-drafter.yml1-49 .github/platform-drafter.yml1-49
The platform-drafter.yml includes an additional filter:
This configuration generates platform-only release notes by filtering changes that affect the openbb_platform/ directory.
Sources: .github/platform-drafter.yml14-16
The platform publishes to PyPI through three deployment workflows: nightly builds, Test PyPI validation, and production PyPI releases.
The nightly build workflow runs daily at UTC+0 and publishes development versions to PyPI:
pyproject.toml with format <currentVersion>.dev<YYYYMMDD>pypa/build and runs python -m buildpypa/gh-action-pypi-publish@release/v1 to upload to PyPIThis provides users continuous access to the latest features without waiting for official releases.
Sources: .github/workflows/README.md33-42
The deploy-test-pypi job activates when pushing to release/* branches:
Trigger Condition:
Workflow Steps:
build package via pipTEST_PYPI_API_TOKEN secretThis validates the package distribution before production release.
Sources: .github/workflows/README.md44-58
The deploy-pypi job activates when pushing to the main branch:
Trigger Condition:
Workflow Steps:
build package via pipPYPI_API_TOKEN secretSources: .github/workflows/README.md44-58
Both deployment workflows use concurrency settings:
This ensures running jobs in the same workflow group are cancelled when a new job triggers, preventing duplicate deployments.
Sources: .github/workflows/README.md51-52
The following diagram shows the end-to-end release pipeline from development through distribution:
| Stage | Actions | Validation |
|---|---|---|
| Development | Create feature branch, implement changes | Pre-commit hooks pass |
| Pull Request | Open PR, automatic labeling | Branch name valid, tests pass |
| Code Review | Team review, address feedback | All checks green |
| Merge | Merge to develop | Draft release updated |
| Release Preparation | Create release/* branch | Version bumped |
| Test Deployment | Push to release/* | Test PyPI package works |
| Production Release | Merge to main | Production PyPI published |
| Distribution | Users install via pip | Package available globally |
Sources: .github/workflows/README.md1-101 .github/release-drafter.yml1-49
The actual workflow definitions are stored in the .github/workflows/ directory:
| Workflow | File | Trigger |
|---|---|---|
| Branch Name Check | .github/workflows/branch-name-check.yml | Pull request to develop/main |
| Auto Labeler | .github/workflows/labeler.yml | Pull request events |
| General Linting | .github/workflows/linting.yml | Pull request, push to feature/hotfix/release |
| Unit test CLI | .github/workflows/unit-test-cli.yml | Pull request events |
| Unit test Platform | .github/workflows/unit-test-platform.yml | Pull request events |
| Integration test API | .github/workflows/integration-test-api.yml | Pull request events |
| Draft Release | .github/workflows/release-drafter.yml | Manual dispatch |
| Deploy Nightly | .github/workflows/deploy-nightly.yml | Daily schedule (UTC+0) |
| Deploy to PyPI | .github/workflows/deploy-pypi.yml | Push to release/*, main, manual |
Sources: .github/workflows/README.md1-101
The build process creates two distribution artifacts in the dist/ directory:
The wheel format provides compiled Python packages for faster installation:
The source distribution includes:
pyproject.toml with dependencies and metadataBoth artifacts are uploaded to PyPI during deployment, allowing pip to choose the optimal format based on the user's platform and Python version.
Sources: .github/workflows/README.md39-41 .github/workflows/README.md55-58
Refresh this wiki