diff options
author | Igor Radovanovic <74266147+IgorWounds@users.noreply.github.com> | 2024-05-14 17:38:06 +0200 |
---|---|---|
committer | GitHub <noreply@github.com> | 2024-05-14 15:38:06 +0000 |
commit | a116d9bbf2fb8f1a5308697cf3b8e651145f26a0 (patch) | |
tree | e18c58745124b74987d72c07f77bf31fa37a694e | |
parent | f87c21ed3cb2607c081b9ebfda4bee292c36a83d (diff) |
[Feature] - OpenBB Platform CLI Unit tests (#6397)
* Unit test batch 1
* CLI controller
* Test batch 3
* Test batch 4
* Test batch 5
* clean some workflows and setup actions
* test
* rename wfs
* rename
* update action
* Skip
* fix cli tests
---------
Co-authored-by: Henrique Joaquim <henriquecjoaquim@gmail.com>
Co-authored-by: Diogo Sousa <montezdesousa@gmail.com>
Co-authored-by: montezdesousa <79287829+montezdesousa@users.noreply.github.com>
35 files changed, 1503 insertions, 417 deletions
diff --git a/.github/scripts/noxfile.py b/.github/scripts/noxfile.py index ed4411601c5..5bc4af2ce43 100644 --- a/.github/scripts/noxfile.py +++ b/.github/scripts/noxfile.py @@ -9,10 +9,12 @@ PLATFORM_DIR = ROOT_DIR / "openbb_platform" PLATFORM_TESTS = [ str(PLATFORM_DIR / p) for p in ["tests", "core", "providers", "extensions"] ] +CLI_DIR = ROOT_DIR / "cli" +CLI_TESTS = CLI_DIR / "tests" @nox.session(python=["3.9", "3.10", "3.11"]) -def tests(session): +def unit_test_platform(session): """Run the test suite.""" session.install("poetry", "toml") session.run( @@ -27,3 +29,19 @@ def tests(session): session.run( "pytest", *PLATFORM_TESTS, f"--cov={PLATFORM_DIR}", "-m", "not integration" ) + + +@nox.session(python=["3.9", "3.10", "3.11"]) +def unit_test_cli(session): + """Run the test suite.""" + session.install("poetry", "toml") + session.run( + "python", + str(PLATFORM_DIR / "dev_install.py"), + "-e", + "all", + external=True, + ) + session.install("pytest") + session.install("pytest-cov") + session.run("pytest", CLI_TESTS, f"--cov={CLI_DIR}") diff --git a/.github/workflows/README.md b/.github/workflows/README.md index 87caf321275..6b03303131b 100644 --- a/.github/workflows/README.md +++ b/.github/workflows/README.md @@ -1,27 +1,9 @@ # OpenBB Workflows + This directory contains the workflows for the OpenBB 🦋 Project. The workflows are: -| Workflows | Summary | Branches -| :-------------------- |:------------------ | :------------------ -| branch-name-check.yml | Checks if the branch name is valid and follows the naming convention. | all branches -| build-release.yml | Builds the project and runs the tests. | main, release/* -| docker-build.yml | Builds the docker image and pushes it to the docker hub. | all branches (only pushes to docker hub on main) -| draft-release.yml | Creates a draft release when a new tag is pushed. | - -| gh-pages.yml | Builds the documentation and deploy to github pages. | main and release/* -| integration-test.yml | Runs the integration tests. | all branches -| labels-issue.yml | Creates an issue when a new bug is reported. | - -| labels-PR.yml | Adds labels to the issues and pull requests. | - -| linting.yml | Runs the linters. | all branches -| macos-build.yml | Builds the project on M1 Macs. | develop, main, release/* -| macos-ml.yml | Builds the project on Mac OS X Full Clean Build with ML. | main -| nightly-build.yml | Builds the project and runs the integration tests every night on the `develop` branch. | develop -| pypi.yml | Publishes the package to PyPI. | all branches (only pushes to PyPI on main) -| pypi-nightly.yml | Publishes the package to PyPI every night on the `develop` branch. | develop -| unit-test.yml | Runs the unit tests. | all branches -| windows_ml.yml | Builds the project on Windows 10 Full Clean Build with ML. | main -| windows10_build.yml | Builds the project on Windows 10. | all branches - -## Branch Name Check Workflow +## 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. @@ -30,137 +12,22 @@ Branches checked: The source branch of a pull request and the target branch of a 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. +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. +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. +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. +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/<feature-name> -- Hotfix branches: hotfix/<hotfix-name> -- Release branches: release/<major.minor.patch>(rc<number>) - -## Build Release Workflow -This GitHub Actions workflow is responsible for building and releasing software for multiple platforms (Windows, M1 MacOS, Intel MacOS, and Docker). -The workflow has four jobs: - -- `trigger-windows-build` -- `trigger-macos-build` -- `trigger-intel-build` -- `trigger-docker-build` - -Each job uses the `aurelien-baudet/workflow-dispatch` action to trigger another workflow, respectively `windows10_build.yml`, `m1_macos_build.yml`, `intel_macos_build.yml`, and `docker.yml`. The `GITHUB_TOKEN` is passed as a secret so that the triggered workflows have access to the necessary permissions. The `wait-for-completion-timeout` is set to 2 hours, which is the maximum amount of time the job will wait for the triggered workflow to complete. - -## Docker Workflow -This GitHub Actions workflow is responsible for building and pushing the docker image to the itHub Container Registry. This workflow is triggered when a new change is pushed to the main branch of the repository, and the Docker image is published to the GitHub Container Registry. - -Steps ------ - -1. Checkout Code: This step checks out the code from the GitHub repository. - -2. Login to GitHub Container Registry: This step logs into the GitHub Container Registry using the GitHub Actions token. - -3. Setup Commit Hash: This step sets the commit hash of the code that is being built. - -4. Build Env File: This step builds the environment file for the Docker image. - -5. Building the Docker Image: This step builds the Docker image using the scripts in the `build/docker` directory. - -6. Publishing the Docker Image: This step publishes the Docker image to the GitHub Container Registry. The Docker image is only pushed to the registry if the branch being built is `main`. - -## Release Drafter Workflow -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. - -## GH Pages Workflow -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. - -## Integration Test Workflow -This GitHub Action is used to run integration tests on your code repository. It is triggered on pushes to the `release/*` or `main` branches, and it runs on the latest version of Ubuntu. - -The workflow consists of the following steps: - -1. Check out the code from the repository -2. Set up Python 3.9 -3. Install Poetry, a package and dependency manager for Python -4. Load a cached virtual environment created by Poetry, to speed up the process if possible -5. Install dependencies specified in the `poetry.lock` file -6. Run the integration tests using the `terminal.py` script -7. Upload a summary of the test results to Slack - -The results of the tests are captured in a file called `result.txt`. The summary of the tests, including information about failed tests, is then uploaded to Slack using the `adrey/slack-file-upload-action` GitHub Action. - -## Linting Workflow -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.9 -- Installing a number of Python packages necessary for the linting tasks -- Running `bandit` to check for security vulnerabilities -- Running `black` to check the code formatting -- Running `codespell` to check the spelling of comments, strings, and variable names -- Running `ruff` to check the use of Python -- Running `mypy` to check the type annotations -- Running `pyupgrade` to upgrade Python 2 code to Python 3 -- Running `pylint` to perform static analysis of the code - -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. - -## MacOS Build Workflow -This GitHub Actions workflow is used to build a version of the OpenBB Platform CLI for M1 MacOS. The build process includes installing necessary dependencies, building the terminal application using PyInstaller, creating a DMG file for distribution, and running integration tests on the built application. - -Jobs ----- - -The workflow consists of a single job named `Build` which runs on self-hosted MacOS systems with ARM64 architecture. The job performs the following steps: - -1. Checkout: The main branch of the repository is checked out, allowing for the commit hashes to line up. -2. Git Log: The log of the Git repository is displayed. -3. Install create-dmg: The `create-dmg` tool is installed using Homebrew. -4. Clean Previous Path: The previous PATH environment variable is cleared and restored to its default values. -5. Setup Conda Caching: The miniconda environment is set up using a caching mechanism for faster workflow execution after the first run. -6. Setup Miniconda: Miniconda is set up using the `conda-3-9-env-full.yaml` environment file, with channels `conda-forge` and `defaults`, and with the `build_env` environment activated. -7. Run Poetry: Poetry is used to install the dependencies for the project. -8. Install PyInstaller: PyInstaller is installed using Poetry. -9. Poetry Install Portfolio Optimization and Forecasting Toolkits: The portfolio optimization and forecasting toolkits are installed using Poetry. -10. Install Specific Papermill: A specific version of Papermill is installed using pip. -11. Build Bundle: The terminal application is built using PyInstaller, with icons and assets copied to the DMG directory. -12. Create DMG: The DMG file is created using the `create-dmg` tool. -13. Clean up Build Artifacts: The build artifacts such as the terminal directory and DMG directory are removed. -14. Save Build Artifact DMG: The DMG file is saved as a build artifact. -15. Convert & Mount DMG: The DMG file is converted and mounted. -16. Directory Change: The current directory is changed to the mounted DMG file. -17. Unmount DMG: The mounted DMG file is unmounted. -18. Run Integration Tests: The built terminal application is run with integration tests, and the results are displayed. - -Finally, the integration tests are run and the results are logged. The workflow is configured to run only when triggered by a workflow dispatch event and runs in a concurrent group, with the ability to cancel in-progress jobs. - -## Nightly Build Workflow -This code is a GitHub Actions workflow configuration file that is used to trigger other workflows when certain events occur. The main purpose of this workflow is to trigger builds on different platforms when a release is made or a pull request is made to the main branch. - -This workflow is triggered at UTC+0 daily by the GitHub Action schedule event. - -The job includes the following steps: - -1. Trigger Windows Build: This step uses the `aurelien-baudet/workflow-dispatch` action to trigger the windows10_build.yml workflow. - -2. Trigger macOS Build: This step uses the `aurelien-baudet/workflow-dispatch` action to trigger the m1_macos_build.yml workflow - -3. Trigger Intel Build: This step uses the `aurelien-baudet/workflow-dispatch` action to trigger the intel_macos_build.yml workflow +- Feature branches: feature/<feature-name> +- Hotfix branches: hotfix/<hotfix-name> +- Release branches: release/<major.minor.patch>(rc<number>) -4. Trigger Docker Build: This step uses the `aurelien-baudet/workflow-dispatch` action to trigger the docker.yml workflow +## Deploy to PyPI - Nightly -This workflow also uses a concurrency setting that groups the jobs by the workflow and ref, and cancels any in-progress jobs. - -## Nightly PyPI Publish Workflow 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. @@ -169,12 +36,13 @@ Then, the code installs `pypa/build` and uses `python -m build` to create a bina Finally, it uses the PyPA specific action `gh-action-pypi-publish` to publish the created files to PyPI. -## PYPI publish Workflow +## 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. +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. +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. @@ -186,47 +54,47 @@ Similarly, the `deploy-pypi` job is triggered only if the pushed branch starts w 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. -## Unit Tests Workflow -This workflow is used to run unit tests on the OpenBB Platform CLI. The workflow is triggered on the following events: -The events this workflow will respond to are: +## Draft release -1. Pull requests that are opened, synchronized, edited, or closed. The pull request must be made to the `develop` or `main` branches. +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. -2. Pushes to the `release/*` branches. +## General Linting -Each job in the workflow specifies a set of steps that are executed in order. +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. -The first job, `check-files-changed`, checks whether there are any changes to certain file types in the repository, such as Python files and lockfiles. If there are changes, then the `check-changes` output variable is set to `true`. +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.9 +- Installing a number of Python packages necessary for the linting tasks +- Running `bandit` to check for security vulnerabilities +- Running `black` to check the code formatting +- Running `codespell` to check the spelling of comments, strings, and variable names +- Running `ruff` to check the use of Python +- Running `pylint` to perform static analysis of the code +- Running `mypy` to check the type annotations +- Running `pydocstyle` to check the docstrings + +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. + +## 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. -The next job, `base-test`, runs a series of tests if `check-changes` is `true` and the base branch of the pull request is `develop`. This job sets up a Python 3.9 environment, installs Poetry, and then runs tests using `pytest`. Finally, it starts the terminal and exits. +## Pull Request Labels -The next job, `tests-python`, runs tests for different versions of Python (3.8, 3.9, and 3.10) on the `ubuntu-latest` operating system. It sets up the specified Python version, installs Poetry and dependencies, and then runs tests using `pytest`. +Automatic labelling of pull requests. -The next job, `full-test`, uses the GitHub Actions `checkout` action to checkout the code, followed by the `setup-python` action to set up the specified version of Python. Then, the `install-poetry` action is used to install the package manager Poetry, and a cache is set up using the `actions/cache` action to avoid re-installing dependencies. After that, the dependencies are installed using Poetry, and a list of installed packages is displayed. Then, the tests are run using `pytest`, and finally, the `terminal.py` script is started and exited. +## 🚉 Integration test Platform (API) -The last job, `tests-conda`, sets up a Miniconda environment using the `setup-miniconda` action. The environment is specified using a YAML file and is activated. Then, the tests are run. +Run `openbb_platform` API integration tests, -## Windows 10 Build Workflow -This is a GitHub Actions workflow file that automates the build and testing process for the OpenBB Platform CLI on Windows 10. The workflow consists of two jobs: +## 🖥️ Unit test CLI -1. Windows-Build -2. Build-Exe +Run `cli` directory unit tests. -- The Windows-Build job does the following: - - Sets up the Windows Git configuration for long file paths. - - Checks out the repository code. - - Sets up Python 3.9 and creates an OpenBB environment using poetry. - - Installs necessary packages and builds the terminal using PyInstaller. - - Uploads the built artifact to GitHub as an artifact. -- The Build-Exe job does the following: - - Sets up the Windows Git configuration for long file paths. - - Checks out the repository code. - - Downloads the built artifact from the previous Windows-Build job. - - Copies the files into an app folder for building the EXE file. - - Builds the EXE file using NSIS. - - Uploads the built EXE as an artifact to GitHub. - - Runs integration tests on the terminal and saves the results to a text file. - - Uploads the test results summary to Slack. - - Cleans up previous build files and artifacts. +## 🚉 Unit test Platform -This workflow is triggered by the `workflow_dispatch` event and runs in concurrency with other workflows in the same group, with the ability to cancel in-progress builds. The concurrency group is defined as `${{ github.workflow }}-${{ github.ref }}`.
\ No newline at end of file +Run `openbb_platform` directory unit tests - providers, extensions, etc. diff --git a/.github/workflows/pypi-nightly.yml b/.github/workflows/deploy-pypi-nightly.yml index 3a3f653df00..3a3f653df00 100644 --- a/.github/workflows/pypi-nightly.yml +++ b/.github/workflows/deploy-pypi-nightly.yml diff --git a/.github/workflows/test_pypi_platform.yml b/.github/workflows/deploy-test-pypi.yml index 54fe09f7dc2..c5a3bb6a375 100644 --- a/.github/workflows/test_pypi_platform.yml +++ b/.github/workflows/deploy-test-pypi.yml @@ -1,4 +1,4 @@ -name: Deploy the OpenBB Platform and the OpenBBTerminal to Test PyPI +name: Deploy the OpenBB Platform to Test PyPI on: push: diff --git a/.github/workflows/draft-release.yml b/.github/workflows/draft-release.yml index 3dab21e7812..01e52ee80d5 100644 --- a/.github/workflows/draft-release.yml +++ b/.github/workflows/draft- |