Skip to content

fiaas/publish

Repository files navigation

publish - Tool to create a release of a Python package

Codacy Quality Badge Codacy Coverage Badge

publish is a tool to package and release a python project. It will create a changelog and upload artifacts to Github and PyPI.

It is created for and by the FIAAS project, and used for most of our projects.

Usage

In order to use publish, you must first install it:

pip install publish

Under the covers, publish uses github-release and twine to do most of the work, and those tools require credentials for Github and PyPI to be available in environment variables:

export GITHUB_TOKEN=gh-token
export TWINE_USERNAME=pypi-user
export TWINE_PASSWORD=pypi-pass

In order to know where to upload the artifacts, you must specify an organization, and a repository:

publish fiaas k8s

Before uploading anything, publish will verify that the current checkout is suitable to be released, and checks the following items:

  • Are all files either ignored or in version control?
  • Is every change committed?
  • Is the currently checked out code tagged with an annotated tag?
  • Does that tag use the convention v<major>.<minor>.<bugfix>?

If the answer to all of these is yes, the name of the tag is used as the version to release. A changelog is generated from the git log, source tarballs and wheels are built, the release is created in Github and PyPI, and the files are uploaded.

When uploading a release to Github, the changelog is attached to the release automatically.

In order for the changelog to be attached to the release on PyPI, it needs to be included in the long description generated by setup.py. To help with this, the changelog is written to a file, and the name of the file is available in an environment variable called CHANGELOG_FILE. Append the contents of this file to your long description, and it will be included in the description on PyPI.

Releasing

To make a new release of this project, there are a couple steps to follow. Ideally, we want to release from master, as often as possible. Version numbers should adhere to SemVer. When you have a passing build that you want to make a release from, do the following steps:

  • Create an annotated tag for the commit in question, naming it v<major>.<minor>.<bugfix>. For instance:

    $ git tag -a v0.0.2 a1b2c3d4
  • Push the new tag to github:

    $ git push origin v0.0.2
  • A new release with the version you selected as a tag should now be built and uploaded to PyPI and Github