Closed danielhollas closed 2 months ago
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 96.17%. Comparing base (
cc4291b
) to head (826ad43
). Report is 3 commits behind head on master.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Cheers @superstar54
Indeed, the tag was not transferred from the forked repo, I've created it manually when making a release. It's nice that you can specify a specific commit for the tag.
It's nice that you can specify a specific commit for the tag.
Now I am confusing again. If the tag has to be create manually, it entirely fallback to the strategy that create the tag to trigger the deployment (upload to PyPI). So in the end, I think we should use create tag to make the release (I think it is also quite standard, no?) What we learned and can added is using this CI review and approve, I don't remember where it is implemented and I am confused why I didn't see it now.
Sorry for confusion. I think this is better to discuss in person (unfortunately I will not be able to make it to today's meeting).
tl;dr IMO the solution here is to always push the release branches to origin, and not forked repo. In fact in the guide on the wiki I've explicitly written that one should always clone a fresh repository to make a release, and I stand by this, because this avoids all kinds of issues:
Also, in case of python packages published on PYPI, pushing the release branch to origin allows you to publish the release on TestPyPI first, where you can verify the package before the actual release. This is not possible to do from fork due to missing PYPI secrets.
pushing the release branch to origin allows you to publish the release on TestPyPI first, where you can verify the package before the actual release.
This is a good point and I totally agree. So we can either always ask to run bumpver
from a newly cloned folder or add a option to bumpver to push to a certain remote. Let's discuss in person.
I want to get a fix in #350 in a new alpha version.
Note, I've specifically opened this PR from my fork, to test @unkcpz observation that the tag from fork will not get transferred to origin when the PR is merged (which is most likely what will happen). In that case, I'll create the tag manually after merge.