18 QA and Release Management
Christiane Ruetten редактировал(а) эту страницу 2018-08-29 18:32:26 +02:00

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:

  1. Bumping the package version in setup.py. This usually lands through a versionbump PR.
  2. Creating a version tag like v3.1.2 pointing to the versionbump merge commit, and then publishing it to the GitHub repo.
  3. Creating and publishing a new latest tag.
  4. 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.

  1. New tags can be listed by clicking on Tags or Show ... newer tags.
  2. Click on Draft a new release.
  3. Enter the new version tag for Tag version. It should show "Existing tag"
    • Never draft releases for the stable or latest tag.
  4. Use the tag message for Release title.
  5. In the form provide a summary of changes.
  6. 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, and pypi 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; use pypitest instead.