Skip to main content

Testing GitHub actions, Cirrus CI, documentation, and publishing releases of Python packages.

Project description


Build Status Code style: black License PyPI Python Version

Dummy project used to test GitHub actions and Cirrus CI for building and publishing releases of Python packages.

This will be a (dummy) Python package on test PyPI in its own right, with package name workflow-sandbox and module name workflow_sandbox.


  • This dummy project loosely adopts the release flow branching model/strategy. (Loosley as I'm not going to always use feature branches.)
  • Versioning is introspected using the excellent setuptools_scm, using the release-branch-semver version scheme.
  • When a release candidate was identified (a574270, C below):
    • A new branch maintenance/0.2.x was created, to service the minor release 0.2.
    • The commit was tagged v0.2.0rc1, the first release candidate of this version.
    • Subsequent untagged commits are versioned (with local scheme no-local-version):
    • On master as 0.3.0devN, e.g. 0.3.0dev1 (ee03672, E below);
    • On maintenance/0.2.x as 0.2.0rc2.dev1 (6006a6f, D below).
  • In this example, the release candidate was deemed satisfactory and a dummy commit was used to create 6006a6f (F below) so that it could be uniquely tagged as v0.2.0.

In pictures, this looks like:

       D -- F [maintenance/0.2.x]
      /     ^ [v0.2.0]
B -- C---E [master]

Update: See #13 for a discussion of why this was necessary and a better alternative (tag C/D with both v0.2.0rc1 and v0.2.0).

Actual releases, e.g. 0.2.0 and bugfix releases 0.2.1, 0.2.2, etc. will be tagged on maintenance/0.2.x alone. This branch will contain no development, but cherry pick bug-fixes from master.


GitHub Actions

  • Create release using actions/create_release.
  • Publish release on GitHub using actions/upload-release-asset...
  • ... with the body above extracted from the appropriate release notes based on git tags (see #14).
  • Using pypa/gh-action-pypi-publish:
    • All tagged releases (including candidates) are published on PyPI and TestPyPI automatically.
    • All untagged pushes to master and maintenance/* branches are published on TestPyPI automatically with an appropriate dev version suffix.
  • Investigate triggering off creation vs branch push events (see #8).
  • Build multiple wheels using a branching workflow actions/[up/down]load-artifact (see e.g. chrisjbillington/desktop-app#7) and/or manylinux (GitHub Action RalfG/python-wheels-manylinux-build).
  • Automated documentation build and push to gh-pages branch.


  • Formatting using black.
  • Linting using flake8.


Much of this is guided by the practices of other development communities, and many helpful conversations with @chrisjbillington and @philipstarkey.

Project details

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

workflow-sandbox-0.5.0.tar.gz (55.5 kB view hashes)

Uploaded source

Built Distribution

workflow_sandbox-0.5.0-py3-none-any.whl (4.7 kB view hashes)

Uploaded py3

Supported by

AWS AWS Cloud computing and Security Sponsor Datadog Datadog Monitoring Fastly Fastly CDN Google Google Download Analytics Microsoft Microsoft PSF Sponsor Pingdom Pingdom Monitoring Sentry Sentry Error logging StatusPage StatusPage Status page