This configures the following CI jobs (mostly following xarray's CI setup, since that's what I'm most familiar with):
ci.yml: main CI, runs on the combination of ubuntu, macos and windows with the supported python versions, according to SPEC0 (3.10, 3.11, 3.12). No 3.13, yet, but should be very easy to add.
nightly.yml: periodically run the tests with upstream versions of the dependencies to get an early warning system for when upstream changes would break this package (uses xarray-contrib/issue-from-pytest-log to open an issue whenever something fails)
pypi.yml: allow using github releases to publish to PyPI. It does so by registering the action in PyPI, then using short-lived tokens to authenticate and push packages (see trusted publishers). Will need some setup like a pypi github environment, though.
There's a couple of tricks I'm using, one of which is to allow using [skip-ci] in the commit message's subject line to skip the main CI, and [test-upstream] to run the nightly CI on a certain commit; use the run-upstream tag to run the nightly CI for all pushes to a PR (if you don't agree with any of the names this should be easy to change, the action that scans the commit message takes the exact string as a parameter).
This configures the following CI jobs (mostly following
xarray
's CI setup, since that's what I'm most familiar with):ci.yml
: main CI, runs on the combination of ubuntu, macos and windows with the supported python versions, according to SPEC0 (3.10, 3.11, 3.12). No 3.13, yet, but should be very easy to add.nightly.yml
: periodically run the tests with upstream versions of the dependencies to get an early warning system for when upstream changes would break this package (uses xarray-contrib/issue-from-pytest-log to open an issue whenever something fails)pypi.yml
: allow using github releases to publish to PyPI. It does so by registering the action in PyPI, then using short-lived tokens to authenticate and push packages (see trusted publishers). Will need some setup like apypi
github environment, though.There's a couple of tricks I'm using, one of which is to allow using
[skip-ci]
in the commit message's subject line to skip the main CI, and[test-upstream]
to run the nightly CI on a certain commit; use therun-upstream
tag to run the nightly CI for all pushes to a PR (if you don't agree with any of the names this should be easy to change, the action that scans the commit message takes the exact string as a parameter).