Rules for Contributing
- All contributions go via pull requests and code review
- Most of pylint warnings should be fixed
- All new files must contain Apache License header (unit test files may not have it)
- All changes must be reflected in Changelog
- All changes must be properly documented
- All changes must be covered with unit tests, no broken tests in master
- Make sure you're on up-to-date master
- Compile Changelog.md record
- Use .change files, remove them later
- Set version and date
- Make sure DockerHub image builds for master
- Send announce if needed
- ... code freeze ...
- Set Release <version> as commit name
- Create git tag with version, make git push, including tag
- Deployment of wheel, site and docker image will be made by Jenkins after testing
- Notify all interested parties (Twitter, mailing lists)
Developing Taurus Extensions
Taurus is an extensible project. You can develop additional modules for it (executors, services, reporters)
in a completely separate codebase. See bzt/resources/base-config.yml to get a feeling of how Taurus
loads all its components.
Additionally, Taurus has a mechanism for automatically detecting configuration files for Taurus plugins.
Here's the conditions:
- Your plugin has to be a Python package installed with the same Python that you're using to run Taurus.
- Your plugin has to have a bzt-configs.json file in the project dir (right next to `__init__.py`).
- In this file should be a JSON list of configuration file names that your project uses to define Taurus modules.
For example, you are developing a Taurus extension with the following structure:
├── __init__.py # package init file, standard for Python
├── hello.py # your plugin module, contains class HelloService
├── 10-hello.yml # configuration file, analogous to base-config.yml
├── bzt-configs.json # configuration index
Contents of bzt-configs.json should be `["10-hello.yml"]`.
Contents of 10-hello.yml:
Adding new Executor
Here is our checklist for a new executor. Also, we have an article