CoPilot analysis
Bonus: fetch-tags workaround may be removable
The appimage workflows have this comment throughout:
#fetch-tags: true # this should work see actions/checkout~issue#1471
...and then manually run git fetch --tags as a workaround. The fetch-tags input bug referenced
in issue #1471 was fixed in a v4.x patch release. After upgrading to v7, it would be worth
testing fetch-tags: true directly and removing the manual git fetch --tags workaround in the
appimage "Create RELEASE-NOTES.txt" steps — though this is independent of the version upgrade
itself.
For example the message string here.
$ git tag --list -n 8.3.536
8.3.536 "Tagging version 8.3.536"
This could contain additional information relating to the authenticity
and signing info should that feature be used. Which is useful to see
with the release info.
Also git_previous_tag resolution is allowed to fail to an empty string.
The situation is due to the difference for tags with message / annotation:
$ git tag -l -n1 8.3.534
8.3.534 "Tagging version 8.3.534"
$ git show-ref -s -d refs/tags/8.3.534
4426cc859e1ec8b6ee1a refs/tags/8.3.534^{}
$ git rev-list -n1 refs/tags/8.3.534
1ec8b6ee1a
Use of rev-lsit will always get the commit ID we expect to see for
the workflow, so we allow either of the SHA above to match at the
point of failure.
This switches the 'remotes/origin/HEAD' and uses the current HEAD of the
current checked out git repo.
Revised the sed rule that is transforming (to be more specific on the
matching regex /-\d+-g/ than just the first /-/):
8.3.530-7-gb64321d4 => 8.3.530+7-gb64321d4 (replace first '-' with '+'
to indicate it is tag plus this many commits)
8.3.530 => 8.3.530 (no change)
This switches to the 'continuous' tag release, that will auto update.
This broke the very old AppImage7 tool since that release not return
HTTP/404. But I updated all to use their current recommendation.
Darryl L. Miles