4.06 KB
Newer Older
1 2 3
# Contributing

[![Commitizen friendly](](
4 5


8 9 10 11 12 13 14 15
When contributing to this repository, it is usually a good idea to first discuss the change you
wish to make via issue, email, or any other method with the owners of this repository before
making a change. This could potentially save a lot of wasted hours.

Please note we have a code of conduct, please follow it in all your interactions with the project.

## Development

16 17 18 19 20 21 22 23 24 25
### Testing

In order to perform tests identical in nature to the integration tests we run then simply ensure you gave gitlab-runner installed then run the following command.

gitlab-runner exec docker test

Keep in mind this will run the tests on your local copy of the master branch so any changes not committed locally will be missed when testing.

26 27
### Commit Message Format

All commits on the repository repository follow the
29 30
[Conventional Changelog standard](
It is a very simple format so you can still write commit messages by hand. However it is
31 32
recommended developers install [Commitizen](,
it extends the git command and will make writing commit messages a breeze.
33 34

Getting Commitizen installed is usually trivial, just install it via npm. You will also
35 36 37
need to install the cz-customizable adapter which the this repository is configured
to use. However the format is simple enough to use manually this makes it easier not to forget,
especially for developers not accustomed to the format yet.
38 39 40 41 42 43 44 45 46 47 48 49


npm install -g commitizen@2.8.6 cz-customizable@4.0.0

Below is an example of Commitizen in action. It replaces your usual `git commit` command
with `git cz` instead. The new command takes all the same arguments however it leads you
through an interactive process to generate the commit message.

![Commitizen friendly](

50 51
Commit messages are used to automatically generate detailed changelogs, and to ensure
commits are searchable in a useful way. So please use the Commitizen tool or adhere to
52 53 54 55 56 57
the commit message standard or else we cannot accept Pull Requests without editing
them first.

Below is an example of a properly formated commit message.

chore(commitizen): Made repository Commitizen friendly.
59 60 61 62 63 64 65 66

Added standard Commitizen configuration files to the repo along with all the custom rules.


### Pull Request Process

1. Ensure that install or build dependencies do not appear in any commits in your code branch.
68 69 70 71 72 73 74 75
2. Ensure all commit messages follow the [Conventional Changelog](
   standard explained earlier.
3. Update the file to add your name to it if it isn't already there (one entry
   per person).
4. Adjust the project version to the new version that this Pull Request would represent. The
   versioning scheme we use is [Semantic Versioning](
5. Your pull request will either be approved or feedback will be given on what needs to be
   fixed to get approval. We usually review and comment on Pull Requests within 48 hours.
76 77 78 79 80 81 82 83 84

### Deploying to Pypi

1. Ensure version number in is correct. Note this is updated in both the version property and the download url.
2. Make sure any outstanding commits are pushed.
3. If a dist/ folder exists delete it.
4. Compile source distribution with `python sdist`
5. Compile binary distribution with `python bdist_wheel`
6. Check the packages for errors with `twine check dist/*`
7. Upload to Pypi using `twine upload dist/*`
86 87 88
8. Create a tag for the current version such as `git tag -a v3.3,3 -m "version 3.3.3"`
9. Push the tag
10. Update the version in and on master.