Packager succeeded but did not create a package

[KyrosKrane]

Summary: I created two tags on the same commit, first an alpha tag, then a release tag. The alpha tag caused an alpha build; the release tag did not create a release at all.

Details:

Earlier today, I pushed a few commits to my addon and tagged them first as v14.0.2-alpha, then more commits, then v14.1.0-alpha. With each tag, the packager correctly built a package.

Here are the action logs for v14.0.2-alpha and v14.1.0-alpha. Both built correctly and created zip files on both GitHub and Curseforge.

After reviewing v14.1.0-alpha, I determined no other changes were needed. I tagged the same commit as v14.1.0-release and pushed the tag. GitHub picked it up and ran the packager; here's the log. The log shows the packager succeeded. But this time, it did not create a new GitHub release, did not create zip files, and didn't upload anywhere. Further, the log indicates that it picked up the alpha tag, not the release tag. (I have two different actions, based on the tag. The release action ran, but the packager script detected the alpha tag. My alphas only upload to Curseforge; releases upload to all the sites.)

In the past, I've done the same steps for other releases; you can see in the git logs how many commits have both an alpha and release tag. For example, both v14.0.0-alpha and v14.0.0-release are on the same commit. It's always packaged the release normally.

To force it to create a new package, I made a trivial commit (changing a comment), tagged it as v14.1.1-release, and pushed. That built correctly and created a package; however the changelog was only from v14.1.0-release, not from v14.0.0-release (the last release prior to these changes).

Any idea why the build for v14.1.0-release detected the alpha tag, not the release tag? And why it didn't end up creating a release zip file?

[nebularg]

Are you using annotated tags?

[KyrosKrane]

Are you using annotated tags?

I'm not sure what that is. When I create a new tag, I do put the same value in the tag name and tag message, if that's what you mean. Example:

[KyrosKrane]

I just looked up the details. It's indeed an annotated tag, as I put a message and sign the tag. Confirmed on the git command line as well.

[nebularg]

Yea, I really have no idea why it didn't use the release tag. It should have, the log shows that it was there. The docs say it should have been used.

I can't reproduce it, so I'm going to just blame github since the packager did what it was suppose to with the output it got from git.

[Nevcairiel]

I assume this is from having two tags on the same commit, and git describe to generate the version was still using the original alpha tag, because why would it have any preference to take one over the other if both are at the same point in history?

Which one it chooses might just be random, and you got lucky in the past.

[nebularg]

nah, it looks at date if there are multiple matches. that's why i asked about annotated tags, lw tags don't have their own object with a date, so git will just (randomly) use whatever is in ref list first

For each commit-ish supplied, git describe will first look for a tag which tags exactly that commit. Annotated tags will always be preferred over lightweight tags, and tags with newer dates will always be preferred over tags with older dates.