Use more robust way to get the most recent tag#7
Use more robust way to get the most recent tag#7NullVoxPopuli wants to merge 1 commit intorelease-plan:mainfrom
Conversation
mansona
left a comment
There was a problem hiding this comment.
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 😞
|
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 |
|
Sigh I fixed it: hokulea/hokulea#244 I adjusted the release script for me and broke it... maybe others did so, too? |
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, butgit describe --abbrev=0 --tagscould not find it, giving this error:I've found that this proposed technique for getting the most recent tag works better.
I've tested it across a variety of repos:
when no tags are found, we get a non-zero exit: