Files
OpenBB/.github/workflows
Boris Li 915bfa48f1 Enterprise Flask Migration Toolkit (#7264)
* feat: Add Flask-to-OpenBB enterprise migration toolkit

- Implement Router.from_flask() for zero-touch legacy API conversion
- Enable 4-hour migration vs 6-month traditional rewrite (80% cost reduction)
- Generate FastAPI endpoints from Flask routes with automatic type validation
- Support enterprise consulting services and custom integration workflows

Demonstrates OpenBB's competitive advantage for institutional client migrations.
Complements existing Workspace applications like Open Portfolio suite.

* chore: Resolve .gitignore conflict and add common ignores

* refactor: implement Phase 1 Flask integration architecture- Move Flask conversion logic to openbb_core.app.utils.flask- Add Flask detection to extension_loader - Integrate with OpenBB's core extension system- Add Flask dependency validation with sys.modules checkingAddresses @deeleeramone's architectural feedback for native OpenBB integration.

* docs: add Flask direct entry point demos- demo_direct_flask_entry_point.py: shows direct Flask instance reference- example_pyproject_flask_entry.toml: demonstrates pyproject.toml configurationSupports new architecture eliminating wrapper extensions.

* Implement Phase 1 Flask adapter per code review feedback

- Minimal working implementation with Flask detection and router creation
- Removes complex code generation logic for focused Phase 1 delivery
- Establishes foundation for Phase 2 route conversion features

* Fix Flask integration: Replace missing FlaskToOpenBBAdapter with WSGIMiddleware

- Remove FlaskToOpenBBAdapter which was not implemented
- Use FastAPI's WSGIMiddleware to mount Flask apps directly
- Update extension_loader to use returned Router object
- Convert utils.py to utils/__init__.py to support flask submodule
- Addresses PR review comment about unhandled AttributeError

* Address PR review feedback: fix Flask imports and remove unused files

- Revert .gitignore to upstream/develop
- Remove AI-generated demo/example files and flask_adapter extension
- Move Flask/werkzeug imports inside conditional blocks to avoid ImportError
- Use lazy imports via __getattr__ in utils/flask/__init__.py
- Add Flask tests with @pytest.mark.skipif markers

* Force APIRouter.include_router to propagate Mount paths instead of dropping them. (#1)

This change ensures that mounted ASGI applications (such as Flask apps wrapped in WSGIMiddleware) are not dropped when `APIRouter.include_router` is called.

Previously, while the initial load in `ExtensionLoader` worked as expected, the `Mount` objects were ignored by FastAPI's default inclusion logic. This caused the mounted elements to be lost during the final application assembly, resulting in 404 errors for the Flask routes.

This fix overrides the inclusion logic to manually propagate `Mount` objects downstream.

* feat(flask): Add metadata layer for OpenAPI documentation

Enhance Flask-to-OpenBB converter with structured docstring parsing:
- Parse Google-style docstrings (summary, description, params)
- Extract parameter descriptions from Args section
- Pass metadata to Router.command() for rich OpenAPI docs

This addresses PR feedback to provide tangible benefit by generating
comprehensive API documentation for migrated Flask routes.

* feat(flask): Implement manual OpenAPI spec generation and attachment

- Add FlaskParam and FlaskRouteInfo TypedDict for type-safe metadata
- Implement OpenAPISpecGenerator for Flask→OpenAPI conversion
- Extract route metadata via FlaskIntrospector
- Attach generated spec to router.openbb_openapi_spec_ext
- Add unit tests (3/3 passing)

Addresses WSGI/mount boundary issue where Router.command metadata
cannot propagate through WSGIMiddleware. Spec attached to router
instance for downstream OpenAPI assembly.

Resolves maintainer feedback on PR #7264

* feat(flask): Implement FlaskMountRegistry for multiple mount support

- Add FlaskMountRegistry class for centralized OpenAPI spec management
- Replace router.openbb_openapi_spec_ext with registry pattern
- Support multiple Flask apps at different mount prefixes
- Automatic path rewriting in aggregated OpenAPI specs
- Add registry test case (4/4 tests passing)

Addresses @deeleeramone's feedback on PR #7264 regarding router
attribute fragility and multiple mount support. Registry provides
lifecycle-independent state management and enables enterprise
scenarios with multiple Flask apps.

Resolves: OpenBB-finance/OpenBB#7264 (partial)

* feat(core): load Flask apps as openbb_core_extension WSGI sub-apps

A Flask app referenced directly by an openbb_core_extension entry point is
mounted via WSGIMiddleware and its routes are introspected into openapi.json
(operationId/widgetId/mcp_tool, parameters, request bodies, security, widget_config
and HTML widgets) so the widget factory and MCP server can discover them.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* test(core): 100% coverage for flask utils + flask dev dependency

Add branch-coverage tests for the Flask integration package (introspection,
AST analysis, docstrings, OpenAPI generation, registry, loader, detection) and
declare flask as a dev dependency so the suite runs in CI.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* fix(flask): treat f-string returns as HTML responses

* fix(flask): mount via a2wsgi instead of deprecated starlette WSGIMiddleware

- add openbb-core[flask] extra (flask, a2wsgi); a2wsgi resolved through require_optional
- run the WSGI serve test through mount_flask_extensions; drop httpx importorskip
- core CI installs [pandas,flask] and httpx2

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* test(flask): cover failed entry point loads; narrow optional types for ty

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

---------

Co-authored-by: Danglewood <85772166+deeleeramone@users.noreply.github.com>
Co-authored-by: deeleeramone <>
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-24 18:19:50 -07:00
..
2026-07-05 15:21:16 -07:00
2026-04-29 21:42:32 -07:00
2026-05-30 00:22:27 -07:00
2026-05-30 00:22:27 -07:00

OpenBB Workflows

This directory contains the workflows for the OpenBB 🦋 Project. The workflows are:

📑 Deploy to GitHub Pages

This GitHub Actions workflow is responsible for building the documentation and deploying it to GitHub Pages. This workflow is triggered when a new change is pushed to the main or release branch of the repository, and the documentation is published to GitHub Pages.

Branch Name Check

Objective: To check if pull request branch names follow the GitFlow naming convention before merging.

Triggered by: A pull request event where the target branch is either develop or main.

Branches checked: The source branch of a pull request and the target branch of a pull request.

Steps:

  1. Extract branch names: Using the jq tool, the source and target branch names are extracted from the pull request event. The branch names are then stored in environment variables and printed as output.

  2. Show Output result for source-branch and target-branch: The source and target branch names are printed to the console.

  3. Check branch name for develop PRs: If the target branch is develop, then the source branch is checked against a regular expression to ensure that it follows the GitFlow naming convention. If the branch name is invalid, a message is printed to the console and the workflow exits with a status code of 1.

  4. Check branch name for main PRs: If the target branch is main, then the source branch is checked against a regular expression to ensure that it is either a hotfix or a release branch. If the branch name is invalid, a message is printed to the console and the workflow exits with a status code of 1.

Note: The GitFlow naming convention for branches is as follows:

  • Feature branches: feature/
  • Hotfix branches: hotfix/
  • Release branches: release/<major.minor.patch>(rc)

Deploy to PyPI - Nightly

This workflow is used to publish the latest version of the OpenBB Platform CLI to PyPI. The workflow is triggered at UTC+0 daily by the GitHub Action schedule event.

It does this by first updating the pyproject.toml file with a pre-determined version string of the form <currentVersion>.dev<date>, where <date> represents the current day's date as a 8 digit number.

Then, the code installs pypa/build and uses python -m build to create a binary wheel and a source tarball in the dist/ directory.

Finally, it uses the PyPA specific action gh-action-pypi-publish to publish the created files to PyPI.

Deploy the OpenBB Platform to Test PyPI

The Github Action code Deploy to PyPI is used to deploy a Python project to PyPI (Python Package Index) and TestPyPI, which is a separate package index for testing purposes. The code is triggered on two events:

  1. Push event: The code is triggered whenever there is a push to the release/* and main branches.

  2. Workflow dispatch event: The code can be manually triggered by the workflow dispatch event.

The code sets the concurrency to the group and the option cancel-in-progress is set to true to ensure that the running jobs in the same group are cancelled in case another job is triggered.

The code contains two jobs, deploy-test-pypi and deploy-pypi, both of which have the same steps with slight variations.

The deploy-test-pypi job is triggered only if the pushed branch starts with refs/heads/release/. This job sets up the Python environment, installs the build package using pip, builds binary wheel and source tarball using build, and finally, publishes the distributions to TestPyPI using the pypa/gh-action-pypi-publish@release/v1 Github Action. The password to access TestPyPI is stored as a secret named TEST_PYPI_API_TOKEN.

Similarly, the deploy-pypi job is triggered only if the pushed branch starts with refs/heads/main. This job follows the same steps as deploy-test-pypi, but the distributions are published to PyPI instead of TestPyPI. The password to access PyPI is stored as a secret named PYPI_API_TOKEN.

Note: The code uses the pypa/build package for building the binary wheel and source tarball, and the pypa/gh-action-pypi-publish@release/v1 Github Action for publishing the distributions to PyPI and TestPyPI.

Draft release

This GitHub Actions workflow is designed to automatically generate and update draft releases in a GitHub repository. The workflow is triggered when it is manually dispatched, allowing you to control when the draft releases are updated.

🧹 General Linting

This GitHub Actions workflow is responsible for running linting checks on the codebase. This workflow is triggered on pull request events such as opened, synchronize, and edited, and push events on branches with names that start with feature/, hotfix/, or release/. The workflow also sets a number of environment variables and uses Github Actions caching to improve performance.

It consists of two jobs: code-linting and markdown-link-check.

The first job, code-linting, runs on an Ubuntu machine and performs several linting tasks on the code in the repository, including:

  • Checking out the code from the repository
  • Setting up Python 3.10
  • Installing a number of Python packages necessary for the linting tasks
  • Running codespell to check the spelling of comments, strings, and variable names
  • Running black to check the code formatting
  • Running ruff to lint the code (replaces pylint, isort, flake8, and pydocstyle)
  • Running ty to check the type annotations

The second job, markdown-link-check, runs on an Ubuntu machine and performs linting of the markdown files in the repository. It uses a Docker container avtodev/markdown-lint to perform the linting.

🏷️ Pull Request Labels

Validate that pull requests do not include the do not merge label.

🚉 Integration test Platform (API)

Run openbb_platform API integration tests,

🖥️ Unit test CLI

Run cli directory unit tests.

🚉 Unit test Platform

Run openbb_platform directory unit tests - providers, extensions, etc.