git tag tarball checksums unstable
selfisekai opened this issue · comments
github-generated tarballs have a little bit of git metadata embeded in the file.
https://github.com/OctoPrint/OctoPrint/blob/master/src/octoprint/_version.py#L22-L26
in the current form, it keeps changing at least once after a release - when a new commit is added to master,
making the tag no longer the HEAD.
--- 1/OctoPrint-1.9.2/src/octoprint/_version.py
+++ 2/OctoPrint-1.9.2/src/octoprint/_version.py
@@ -23,7 +23,7 @@
# setup.py/versioneer.py will grep for the variable names, so they must
# each be defined on a line of their own. _version.py will just call
# get_keywords().
- git_refnames = " (HEAD -> master, tag: 1.9.2)"
+ git_refnames = " (tag: 1.9.2)"
git_full = "f027aaa7300f70b046525a49245b33c43dd198c1"
keywords = {"refnames": git_refnames, "full": git_full}
return keywordsthis is an issue in distributions, often a recurring one:
- https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/49445
- NixOS/nixpkgs#261934
- https://aur.archlinux.org/cgit/aur.git/commit/?h=octoprint&id=90a6edd35284fac8c1ff4e8baf07486b6f3d9593
solutions to consider:
- release own tarballs (generated in github actions) via github releases
- rework the way git metadata is attached (to keep it stable)
- remove the git format mark at all, bump version in a file manually?
system info not applicable to the issue
You could work around this by fetching the latest version from PyPi instead of GitHub, which already gets the fixed packages uploaded on release, but I'll also see that I can add the release packages as separate downloads to the release.
You could work around this by fetching the latest version from PyPi instead of GitHub, which already gets the fixed packages uploaded on release, but I'll also see that I can add the release packages as separate downloads to the release.
For us (nixpkgs) the problem would be the missing tests in PyPi..
Gotcha. As I said, I'll see that the release artifacts that are created by the release test and build workflow are attached to the release going forward, I hope that'll solve this. I have no control of the source zip however, and I need the embedded git metadata in there for automatic versioning.
With the above commit it assets should hopefully be attached to the release from 1.10.0rc1 forward. We'll see if the CI actually does what it's supposed to do then. If not, I'll adjust the workflow as needed. Steps looked good on a test repo however.