Содержание
The following cheat sheet assumes that TLS Canary's GitHub repo was cloned locally and the package installed with
pip install -e .[dev]
Running tests
$ python setup.py test # What Travis.CI runs
$ nosetests -sv # more flexible
$ nosetests -sv -e zz_ # excludes the long-running integration tests
Coverage
$ nosetests --with-coverage --cover-package=tlscanary --cover-branches --cover-erase --cover-html
$ firefox coverage/index.html
Code complexity analysis
This requires installing the Radon package with pip install radon
.
Cyclomatic complexity
$ RADONFILESENCODING=utf-8 radon cc tlscanary -s
Maintainability index
$ RADONFILESENCODING=utf-8 radon mi tlscanary -s
LOC, LLOC, SLOC, ...
$ RADONFILESENCODING=utf-8 radon raw tlscanary -s
Release process
TLS Canary is released to two services: GitHub and the official PyPI package index.
GitHub
GitHub releases are based on tags. TLS Canary uses the following tag scheme:
Tag format | Purpose |
---|---|
v3.1.2 | Versioned stable release tags |
v3.2.0a1 | Versioned experimental release tags |
stable | Points to the latest stable release |
latest | Points to the latest (potentially experimental) release |
Making a GitHub release usually requires the following steps:
- Bumping the package version in
setup.py
. This usually lands through a versionbump PR. - Creating a version tag like
v3.1.2
pointing to the versionbump merge commit, and then publishing it to the GitHub repo. - Creating and publishing a new
latest
tag. - For stable releases: Creating and publishing a new
stable
tag.
Pulling and listing current tags
$ git fetch origin --tags
$ git tag --list -n1
Listing all local tags and their commits
$ git tag -l | while read tag ; do echo $tag $(git rev-list -n 1 $tag) ; done
And yes, it is that complicated.
Creating and publishing a signed tag
Check out the commit you want to tag and then:
$ git tag --sign <TAG> -m "<TAG_MESSAGE>" [--force]
$ git push origin <TAG> [--force]
- Replacing existing tags requires
--force
. - Use
refs/tags/<TAG>
for pushes if there is a local branch of the same name. - You have to provide a tag message. Examples:
Tag | Example message |
---|---|
v3.0.0 | TLS Canary major release 3.0.0 |
v3.1.0 | TLS Canary feature release 3.1.0 |
v3.1.1 | TLS Canary hotfix release 3.1.1 |
v3.1.2 | TLS Canary bugfix release 3.1.2 |
stable | TLS Canary latest stable release: 3.1.2 |
latest | TLS Canary latest experimental release: 3.2.0a1 |
Declaring releases on GitHub
Releases must be explicitly declared through the repo's release interface.
- New tags can be listed by clicking on Tags or Show ... newer tags.
- Click on Draft a new release.
- Enter the new version tag for Tag version. It should show "Existing tag"
- Never draft releases for the stable or latest tag.
- Use the tag message for Release title.
- In the form provide a summary of changes.
- If you decide to announce an experimental release this way, also tick This is a pre-release.
PyPI
Put this in your ~/.pypirc:
[distutils]
index-servers =
pypi
pypitest
[pypi]
repository = https://upload.pypi.org/legacy/
username = moz_tlscanary
password = ASK_CR_FOR_PASSWORD
[pypitest]
repository = https://test.pypi.org/legacy/
username = moz_tlscanary
password = ASK_CR_FOR_PASSWORD
- This gives you access to two
python setup.py sdist
backends,pypitest
for test publishing and publishing experimental packages, andpypi
for publishing official release versions. - The credentials also give you access to PyPI's web interface where you can manage published package versions and upload your PGP key used for signing packages.
- The config is still using PyPI's legacy API which may require updating soon.
Creating a local package for testing
$ python setup.py sdist build
- Packages are written to the
dist/
folder.
Publishing experimental releases to PyPI Test
python setup.py sdist upload -r pypitest
These are accessible via
$ pip search -i https://test.pypi.org/pypi tlscanary
$ pip install -i https://test.pypi.org/pypi tlscanary [--pre]
The --pre
argument to pip install
is required for installing pre-release versions when the repository also holds release versions. In that case, default install will only consider the latest release version.
Hence you should not publish release version to PyPI Test or make sure to remove them after testing.
Publishing official signed releases to PyPI
$ python setup.py sdist upload -r pypi --sign
- Make sure that you're using a PGP key that is registered with PyPI.
- Never publish experimental releases to
pypi
; usepypitest
instead.