Files
anybadge/CONTRIBUTING.md
Jon Grace-Cox 1c986d4ad8 Add package testing to CI (#68)
* Make `build_examples.py` callable from python
* Allow tests to run from outside project directory
* Add invoke tasks
* Add server tests
* Run travis tests against wheel package instead of local code
* Update `badge.write_badge()` to support `pathlib.Path`
* Update `CONTRIBUTING.md`
2022-08-13 13:22:15 -04:00

5.8 KiB

Contributing to anybadge

I love your input! I want to make contributing to this project as easy and transparent as possible, whether it's:

  • Reporting a bug
  • Discussing the current state of the code
  • Submitting a fix
  • Proposing new features
  • Becoming a maintainer

I use Github Flow, so all code changes happen through pull requests

Pull requests are the best way to propose changes to the codebase (I use Github Flow). I actively welcome your pull requests:

  1. Fork the repo and create your branch from master
  2. If you've added code that should be tested, add tests
  3. If you've changed APIs, update the documentation
  4. Ensure the test suite passes
  5. Make sure your code lints (tbc)
  6. Issue that pull request!

Any contributions you make will be under the MIT Software License

When you submit code changes, your submissions are understood to be under the same MIT License that covers the project. Feel free to contact the maintainers if that's a concern.

Report bugs using Github's issues

I use GitHub issues to track public bugs. Report a bug by opening a new issue.

Write bug reports with detail, background, and sample code

Great Bug Reports tend to have:

  • A quick summary and/or background
  • Steps to reproduce
    • Be specific!
    • Give sample code if you can (ideally sample code that anyone with a basic setup can run to reproduce)
  • What you expected would happen - (include explanation, screenshot, drawings, etc. to be exact)
  • What actually happens
  • Notes (possibly including why you think this might be happening, or stuff you tried that didn't work)

People love thorough bug reports.

Use a Consistent Coding Style

Please follow the existing coding style. Your code should be standardised using Python Black using pre-commit when you make commits - please ensure you have pre-commit installed (see here).

License

By contributing, you agree that your contributions will be licensed under its MIT License.

Development environment

Setup your development environment with the following steps:

Check out the project

Clone the project:

git clone https://github.com/jongracecox/anybadge.git

Install build requirements

Install build requirements with:

pip install -r build-requirements.txt

Install pre-commit

This projects makes use of pre-commit to add some safety checks and create consistency in the project code. When committing changes to this project, please first install pre-commit, then activate it for this project:

pip install pre-commit
pre-commit install

After installing pre-commit to your project (with pre-commit install), committing to the project will trigger a series of checks, and fixers. This process may reject your commit or make changes to your code to bring it into line with the project standards. For example, Python black will be used to reformat any code. When changes are made by these pre-commit hooks you will need to re-add and commit those changes in order for pre-commit to pass.

Here is some example output from pre-commit:

trim trailing whitespace.................................................Failed
- hook id: trailing-whitespace
- exit code: 1
- files were modified by this hook

Fixing tests/test_anybadge.py

fix end of files.........................................................Failed
- hook id: end-of-file-fixer
- exit code: 1
- files were modified by this hook

Fixing examples/color_teal.svg

This shows that two files were updated by hooks, and need to be re-added (with git add) before trying to commit again.

Development activities

Invoke

The project has some Python invoke tasks to help automate things. After installing build requirements you can run inv --list to see a list of available tasks.

For example:

> inv --list
Available tasks:

  build                 Build the package.
  clean                 Clean up the project area.
  examples              Generate examples markdown.
  server.docker-build
  server.docker-run
  server.run
  test.docker           Run dockerised tests.
  test.local            Run local tests.

You can get help for a command using inv --help <command>.

Invoke tasks are defined in the tasks/ directory in the project. Feel free to add new and useful tasks.

Running tests

You can run tests locally using:

inv test.local

When running locally, you will be running tests against the code in the project. This has some disadvantages, specifically running locally may not detect files that are not included in the package build, e.g. sub-modules, templates, examples, etc. For this reason we have a containerised test. This can be run using:

inv test.docker

This will clean up the project dist directory, build the package locally, build the docker image, spin up a docker container, install the package and run the tests. The tests should run using the installed package and not the project source code, so this method should be used as a final test before pushing.

Documentation

The README.md file contains a table showing example badges for the different built-in colors. If you modify the appearance of badges, or the available colors please update the table using the invoke task:

inv examples