lunarmodules / luacheck

A tool for linting and static analysis of Lua code.

Home Page:https://luacheck.readthedocs.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

`latest` tag as annotated tag affects tooling

mblayman opened this issue · comments

Hi, luacheck devs,

I'd like to check if it's possible to modify the release process for luacheck.

With the recent release of v0.26.0, the latest tag was added was added to the release commit. As something that is a "moving" tag, I believe that it's causing some issues with tooling that depends upon tags.

For instance, I use pre-commit.ci and this CI system will auto-update the project's pre-commit config file with the most recently tagged version. Because of the latest tag acting as an annotated tag, pre-commit.ci is trying to, incorrectly, update my config file from a specific version to the non-specific latest tag (https://github.com/mblayman/atlas/pull/29/files).

After chatting with pre-commit's maintainer (https://twitter.com/codewithanthony/status/1508639777171640326) and looking at https://stackoverflow.com/questions/11514075/what-is-the-difference-between-an-annotated-and-unannotated-tag, it appears that this problem could be avoided if latest was not treated as an annotated tag.

I think that would be:

git tag latest

instead of:

git tag -a latest -m 'Some annotation message'

I'm not sure how latest is currently attached as a label on project. Could this be changed to avoid this tooling conflict?

Thanks for the consideration.

Hey and thanks for bringing this up. I'm happy to work towards a solution that works one way or another for all use cases.

Unfortunately I don't think this has been diagnosed correctly. The latest tag is not an annotated tag, it (along with the v0 tag) is just a regular bare pointer to the commit. There is no annotation message on it (not even a blank one).

I actually personally hate the whole sliding tag system, but GitHub has adopted this as practically the only effective way to manage GitHub Action releases. The latest tag and major version tags like v0 will be required for the Action stuff to function correctly.

I believe the solution is to limit the automated release checking stuff like pre-commit's update bot to looking for stable release patterns. Starting with v0.26.0 all stable releases will be prefixed with v and use a full thee-part semver string, so tags should be filtered for ^v\d+\.\d+\.\d+$ (adapt to whatever pattern/regex matching you have at hand) done before comparing versions.

Another possibility is to use GitHub's API to query the latest release (not to be confused with the latest tag which is a completely different mechanism!). The latest keyword in the URL such as https://github.com/lunarmodules/luacheck/releases/latest will always redirect to the proper semver tag as I am marking them as GitHub Releases (not just tags). There is also a corresponding API call that can be used to get the corresponding tag.

I see. Apologies for the misdiagnosis and thank you for the detailed feedback. I did git show latest and saw some message, so I incorrectly surmised that it was an annotated tag.

The other thing in that tweet that the maintainer noted is that it could be that "there's a moving tag that's ahead of the latest tag (generally that should be a branch and not a tag)."

I wonder if the fact that there's a v0 tag may be part of the issue. Also, perhaps the fact that the tag SHA is shared with the annotated v0.26.0 tag is what is truly causing the issue.

I'll share this issue with the pre-commit maintainer. The fact that luacheck is using a public actions-tagger action might be something that he'll want to be aware if it causes a behavior that undesirable in pre-commit.ci.

Thanks!

If you run git show on a regular tag it will just show you the commit that was tagged—regular tags are just pointers to commit hashes anyway. If you do it on an annotated tag you will see two sets of details: the commit but also the annotation which will include a message, have a tag author, can be signed, etc.

The actions-tagger utility I'm using to keep the latest & major version tags up to date is not an official GitHub action, but it was specifically built to follow the official versioning guide. The latest/v0 tags are bumped after releases chronologically (by necessity of being triggered by actual release tags), but semantically they are exactly the same pointers to the same commits, so "after" isn't really meaningful here.

When looking for the latest release, tags should be filtered to match the specification for the tags you want. I'm happy to talk to the pre-commit folks if I can be of assistance working something out.