workflow-sandbox
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
.
Practices
- 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 therelease-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 release0.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
as0.3.0devN
, e.g.0.3.0dev1
(ee03672, E below); - On
maintenance/0.2.x
as0.2.0rc2.dev1
(6006a6f, D below).
- A new branch
- 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]
^
[v0.2.0rc1]
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.
Roadmap
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
andmaintenance/*
branches are published on TestPyPI automatically with an appropriatedev
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.
CirrusCI
- Formatting using
black
. - Linting using
flake8
.
Acknowledgements
Much of this is guided by the practices of other development communities, and many helpful conversations with @chrisjbillington and @philipstarkey.