Automated Testing for Lightning EcoSystem Projects
Automate issue discovery for your projects against Lightning nightly and releases.
You get CPUs, Multi-GPUs testing for free, and Slack notification alerts if issues arise!
You get CPUs, Multi-GPUs testing for free, and Slack notification alerts if issues arise!
Here are pre-requisites for your project before adding to the Lightning EcoSystem CI:
- Your project already includes some Python tests with PyTorch Lightning as a dependency
- You'll be a contact/responsible person to resolve any issues that the CI finds in the future for your project
- First, fork this project (with CLI or in browser) to be able to create a new Pull Request, and work within a specific branch.
gh repo fork Lightning-AI/ecosystem-ci cd ecosystem-ci/
- Copy the template file in
configs
folder and call it<my_project_name>.yaml
.cp configs/template.yaml configs/<my_project_name>.yaml
- At the minimum, modify the
HTTPS
variable to point to your repository. See Configuring my project for more options.If your project tests multiple configurations or you'd like to test against multiple Lightning versions such as master and release branches, create a config file for each one of them. As an example, have a look at metrics master and metrics release CI files.source_repository: HTTPS: https://github.com/MyUsername/MyProject.git ...
- Define your
runtimes
(OS and Python version) in your config file to be executed on CPU and/or add the config filename in the Azure GPU CI file.- For CPU integration, specify the OS and Python version combinations inside your config file:
runtimes: - {os: "ubuntu-20.04", python: "3.9"} - {os: "macOS-12", python: "3.7"} - {os: "windows-2019", python: "3.8"} ...
- For GPU integration, add your config filename in the Azure GPU CI file file:
... jobs: - template: testing-template.yml parameters: configs: - "Lightning-AI/metrics_pl-develop.yaml" - "Lightning-AI/metrics_pl-release.yaml" - "MyUsername/my_project-master.yaml"
- For CPU integration, specify the OS and Python version combinations inside your config file:
- Add the responsible person(s) to CODEOWNERS for your organization folder or just the project.
# MyProject /configs/Myusername/MyProject* @Myusername
- Finally, create a draft PR to the repo!
- To qualify for GPU machines we require your project to have 100+ GitHub stars (please note that this is for capacity reasons and may change in the future)
- (Optional) Join our Slack channel
#alerts-ecosystem-ci
to be notified if your project is breaking - (Kind request) include Lightning badge in your readme:
[![Lightning](https://img.shields.io/badge/-Lightning-792ee5?logo=pytorchlightning&logoColor=white)](https://lightning.ai)
The config include a few different sections:
source_repository
include your projectenv
(optional) define any environment variables required when running testsdependencies
listing all dependencies which are taken outside piptesting
defines specific pytest arguments and what folders shall be tested
All dependencies as well as the target repository is sharing the same template with the only required field HTTPS
and all others are optional:
source_repository:
HTTPS: https://github.com/Lightning-AI/metrics.git
username: my-nick # Optional, used when checking out private/protected repo
password: dont-tell-anyone # Optional, used when checking out private/protected repo
token: authentication-token # Optional, overrides the user/pass when checking out private/protected repo
checkout: master # Optional, checkout a particular branch or a tag
install_extras: all # Refers to standard pip option to install some additional dependencies defined with setuptools, typically used as `<my-package>[<install_extras>]`.
# Optional, if any installation/tests require some env variables
env:
MY_ENV_VARIABLE: "VAR"
copy_tests:
- integrations # copied folder from the original repo into the running test directory
# this is copied as we use the helpers inside integrations as regular python package
- tests/__init__.py
- tests/helpers
# Optional, additional pytest arguments and control which directory to test on
testing:
dirs:
- integrations
pytest_args: --strict
Note: If you define some files as done above, and they are using internal-cross imports, you need to copy the __init__.py
files from each particular package level.
The testing
section provides access to the pytest run args and command.
testing:
# by default pytest is called on all copied items/tests
dirs:
- integrations
# OPTIONAL, additional pytest arguments
pytest_args: --strict