[Bug]: Release tag missing `v` prefix
stevehipwell opened this issue · 13 comments
Is there an existing issue for this?
- I have searched the existing issues
Current Behavior
The latest release tag is 1.14.0 which is breaking automation which expects a v prefix.
Expected Behavior
I'd expect the latest release tag to be v1.14.0.
Reference Chart
N/A
Reference Template
No response
Environment
- Operating system:
- Helm version (output of
helm version): - GO version (output of
go version): - Method of calling
helm-docs(manual, jenkins, github action ...):
Link to helm-docs Logs
No response
Further Information
No response
Came here to say this
@norwoodj FYI this issue is blocking automation which relies on the tag structure to retrieve the latest version of helm-docs.
Dammit, sorry haven't released this in a while and I don't have a check for this in the release script
@norwoodj if you add a v prefix to the release GH Actions workflow it's only run for a valid tag.
name: Release
on:
push:
tags:
- v*My suggestion would be to release v1.14.0 & v1.14.1 off the same commits as the non v prefixed versions. I would then update the description of the incorrect releases to say as much. And finally I'd release v1.14.2 to make sure that there is no ambiguity on the correct release format. Would you like a PR to make the above change to be used as the commit for a v1.14.2 release?
Hey @stevehipwell. I'm sorry about the mistake, I'm an idiot. I have re-released those tags with the correct format, and will release a v1.14.2 like you suggest with some new checks in both the github action and release script.
Thanks for the quick response @norwoodj.
On a related topic I've noticed that the current GitHub actions workflows use sliding tag based references, would you be interested in a PR to switch these over to the recommended deterministic SHA based pattern (e.g. uses: actions/checkout@v4 -> uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7)? Dependabot works correctly with this pattern to keep them up to date so there is minimal additional overhead for a significant increase in both security and reporoducability.
Hey @stevehipwell. I'm sorry about the mistake, I'm an idiot. I have re-released those tags with the correct format, and will release a v1.14.2 like you suggest with some new checks in both the github action and release script.
Thanks for the quick fix, @norwoodj! .. Rest assured that these kinds of mistakes never happy to any of us reading along here 😉
Hey, I'd appreciate a PR to do that a lot. Other folks set up all the github action stuff for me, so I don't really know what best practices here are 😅
Happy to accept a PR which improves things on that front.
Let me know if there are any other problems with the tagging, I believe the fixes I just made should correct things.