GitHub workflows for testing & publishing

CAIIVS / chuchichaestli

Where you find all the state-of-the-art cooking utensils (salt, pepper, gradient descent... the usual).

GNU General Public License v3.0

3 stars 0 forks source link

GitHub workflows for testing & publishing #17

Closed phdenzel closed 3 months ago

phdenzel commented 4 months ago

workflow for running pytest on Python version 3.10, 3.11., 3.12
workflow for publishing pushes and PR to main as releases, packages to TestPyPI, and tagged pushes and PR to PyPI

phdenzel commented 4 months ago

We should probably introduce a pre-release versioning scheme, so we don't have conflicts with PyPI and especially Test PyPI.

bil-y commented 4 months ago

We should probably introduce a pre-release versioning scheme, so we don't have conflicts with PyPI and especially Test PyPI.

We could add the git hash to the version, but I don't see an immediate option to achieving this with hatch / pip / build.

phdenzel commented 4 months ago

We should probably introduce a pre-release versioning scheme, so we don't have conflicts with PyPI and especially Test PyPI.

We could add the git hash to the version, but I don't see an immediate option to achieving this with hatch / pip / build.

I figured out how to skip the test-pypi build when the version already exists... so, if we need to test a new build, we just have to change the version manually. I think that's good enough for now, everything else is automated.

bil-y commented 4 months ago

We should probably introduce a pre-release versioning scheme, so we don't have conflicts with PyPI and especially Test PyPI.

We could add the git hash to the version, but I don't see an immediate option to achieving this with hatch / pip / build.

I figured out how to skip the test-pypi build when the version already exists... so, if we need to test a new build, we just have to change the version manually. I think that's good enough for now, everything else is automated.

Never mind my previous reply, there is hatch version [version string]. The version string has to be PEP440 compliant. PEP440 defines both a "public" and a "local" version string.

So, after a release, we could bumb the patch version and add a dev1. E.g. 0.0.1 -> 0.0.2.dev1 Then, using the local version, we can do the following: 0.0.2.dev1+[commit hash]

phdenzel commented 3 months ago

Workflow "executive summary":

for PR to main:
- building & testing Python 3.10, 3.11, 3.12
- automatic publishing to TestPyPI (if version is new)
- auto bump dev version (e.g. 0.0.1.dev3 -> 0.0.1.dev4)
for tagged pushes on main:
- building & testing Python 3.10, 3.11, 3.12
- automatic publishing to PyPI (if version is new)
- auto bump micro version (e.g. 0.0.1 -> 0.0.2)

phdenzel commented 3 months ago

Ready to be merged from my side.