Use more robust way to get the most recent tag

[NullVoxPopuli]

I've run in to this a lot on several repos setting up release-plan for the first time.

Most recently, on the repo for esyes. There was one prior tag, but git describe --abbrev=0 --tags could not find it, giving this error:

 stdout: 'Error: Command failed with exit code 128: git describe --abbrev=0 --tags\n' +
    "fatal: No tags can describe 'c37611084aa5f41f1ab7a357517e596dc5603cfd'.\n" +
    'Try --always, or create some tags.\n' +
    '    at makeError (/home/nvp/Development/OpenSource/starbeam/esyes/node_modules/.pnpm/[email protected]/node_modules/execa/lib/error.js:60:11)\n' +
    '    at module.exports.sync (/home/nvp/Development/OpenSource/starbeam/esyes/node_modules/.pnpm/[email protected]/node_modules/execa/index.js:194:17)\n' +
    '    at Object.lastTag (/home/nvp/Development/OpenSource/starbeam/esyes/node_modules/.pnpm/@[email protected]/node_modules/@ef4/lerna-changelog/lib/git.js:31:18)\n' +

I've found that this proposed technique for getting the most recent tag works better.
I've tested it across a variety of repos:

❯ git describe --tags `git rev-list --tags --max-count=1`
[email protected]

❯ git describe --tags `git rev-list --tags --max-count=1`
v3.4.3-@embroider/compat

❯ git describe --tags `git rev-list --tags --max-count=1`
[email protected]

❯ git describe --tags `git rev-list --tags --max-count=1`
[email protected]

when no tags are found, we get a non-zero exit:

❯ git describe --tags `git rev-list --tags --max-count=1`
fatal: No names found, cannot describe anything.

❯ echo $?
128

[mansona]

So first of all, I like the direction of this work. I recently was trying to convince someone to use release-plan on a new project and the initial experience wasn't great so I want to improve it for sure.

I'm a little bit skeptical that this is the right behaviour though 🤔 you say that this is trying to get the "most recent tag" but that's not always what you want. You want the most recent tag on your branch so that you can use release-tag to deploy legacy versions of things. Do you happen to know if that is what this does?

I also feel very conflicted about merging such a fundamental change without having any tests. I know that might be a bit hard to do since we need a real git repo to do verify the nuances that I'm asking about, but we really need to put our heads together and figure out a way to test this before we merge 😞

[gossi]

I see this now as well for me, but it is a different story for why it appears.

On my local machine I can do everything manually and it works. On GH Actions, I see the error. Here is the most recent one: hokulea/hokulea#239

All of that began to happen, when I switched away from volta, here is my PR: hokulea/hokulea#219 (before that PR, release-plan was working as expected).

So some notion of context/environment? Maybe git version or so is different? (I haven't checked that)

[gossi]

Sigh I fixed it: hokulea/hokulea#244

I adjusted the release script for me and broke it... maybe others did so, too?