search

neuroinformatics-unit / python-cookiecutter

Utility to create a basic Python project structure with tests, CI etc.
BSD 3-Clause "New" or "Revised" License
22 stars 3 forks source link

Run actions on pushed tag #16

Closed adamltyson closed 1 year ago

adamltyson commented 1 year ago

Aim to fix #15

Need to test this a bit more, but I think it works

niksirbi commented 1 year ago

I created a version tag locally on a test repo and pushed it to GitHub (this worked), but the build didn't get triggered. Could it be because I haven't connected the repo to PyPi yet (no TWINE_API_KEY in repo secrets)

adamltyson commented 1 year ago

Hmm, that should trigger the build, but the upload would fail. Could you link to that repo?

adamltyson commented 1 year ago

@niksirbi did you specifically push the tag too?

niksirbi commented 1 year ago

I ran git push -u origin main --follow-tags Here is the repo: https://github.com/niksirbi/test-repo

niksirbi commented 1 year ago

Correction @adamltyson . The builds appear to be here?

adamltyson commented 1 year ago

This looks fine to me. The distributions are built, but the upload fails with an authentication error. Could you test by:

niksirbi commented 1 year ago

So I added a TWINE_API_KEY to my test repo and managed to release it on TestPypi with only a slight modification to the deployment action.

The triggered releases don't appear on GitHub as releases though (despite being up on TestPypi), I don't know if that's a problem.

adamltyson commented 1 year ago

The triggered releases don't appear on GitHub as releases though (despite being up on TestPypi), I don't know if that's a problem.

That's fine, they aren't actually "GitHub releases", although we're releasing them via GitHub.

niksirbi commented 1 year ago

Moreover, setuptools_scm has a peculiar behavior: After I create and push a tag (e.g. v0.0.3), if I prompt it with python -m setuptools_scm it returns 0.0.3 as expected. However, if I make further commits, without creating a new tag, the reported version is sth like 0.0.4.dev1+g09e49d9. I guess this particular version acts as a development (or rc) version of 0.0.4. We can still create rc versions manually by adding tags such as v0.0.7rc1, but after every deviation, setuptools_scm will append a hash to it. I guess our intention is NOT to release all the dev+... versions on PyPi, but this means that setuptools_scm will locally report a more granular version of the package.

niksirbi commented 1 year ago

Is the above behaviour somehow altered by this PR?

adamltyson commented 1 year ago

Moreover, setuptools_scm has a peculiar behavior: After I create and push a tag (e.g. v0.0.3), if I prompt it with python -m setuptools_scm it returns 0.0.3 as expected. However, if I make further commits, without creating a new tag, the reported version is sth like 0.0.4.dev1+g09e49d9. I guess this particular version acts as a development (or rc) version of 0.0.4. We can still create rc versions manually by adding tags such as v0.0.7rc1, but after every deviation, setuptools_scm will append a hash to it.

That's the default, designed behavior of setuptools_scm. I'm not sure I see the benefit, but it's worth it to adopt a commonly-used package.

I guess our intention is NOT to release all the dev+... versions on PyPi, but this means that setuptools_scm will locally report a more granular version of the package.

Yeah, I think we would only release specific versions we define ourselves. setuptools_scm will only report a more granular version if the code is cloned (or installed directly) from GitHub. If users install from PyPI, it should report the "clean" version.

niksirbi commented 1 year ago

All clear. I will approve this PR now and you may merge.

adamltyson commented 1 year ago

Is the above behaviour somehow altered by https://github.com/SainsburyWellcomeCentre/python-cookiecutter/pull/18?

Nope, they should be independent.