* 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`
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:
- Fork the repo and create your branch from
master
- If you've added code that should be tested, add tests
- If you've changed APIs, update the documentation
- Ensure the test suite passes
- Make sure your code lints (tbc)
- 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