-
Notifications
You must be signed in to change notification settings - Fork 7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Helm version for v3.15.0 reports v3.15.0-rc.2 #13040
Comments
@mattfarina could you take an review? thanks so much. |
Confirmed, seeing the same on the |
We've temporary pinned 3.14.4 for GitHub Actions / Azure DevOps. Please drop a confirmation that it's expected behaviour for us to unlock updates of Helm. Thanks in advance. |
This is interesting because the both tags point to the same commit. When this was created, the release tag was added and CI did the build. So, how do we get CI to handle the tags properly? |
If I look at the
When I run this in Linux environments, I get the release version. I'm not able to duplicate it. But, the wrong version shows up in the release job and the release job checkout out the exact right tag. We need to update the build job (GHA workflow) to make sure the |
@mattfarina maybe we can rerelease? |
Encountered this due to |
Uhm isn't that even worse that homebrew ships a different binary? |
@TheMeier this isn't unusual in open source. |
@TheMeier open source is about the source code rather than the builds. For example, pretty much everyone uses curl. The curl projects does not distribute binaries. Everyone gets them from their OS, package manager, etc. It's not just acceptable but expected to have different builds of the same source. |
The release process had selected the tag to use as the version automatically. But, this presented a problem when a release candidate and final release pointed to the same commit id. For a long time it had automatically selected the final release. But, we ran into a problem where it selected the RC tag instead of the final release. This change explicitly tells the build scripts the version to use based on the tag passed into the CI run. It should no longer try to self discover the version. Closes helm#13040 Signed-off-by: Matt Farina <matt@mattfarina.com>
The pull request at #13059 provides a simple fix. The tag is passed in as the explicit version rather than being automatically detected. |
The release process had selected the tag to use as the version automatically. But, this presented a problem when a release candidate and final release pointed to the same commit id. For a long time it had automatically selected the final release. But, we ran into a problem where it selected the RC tag instead of the final release. This change explicitly tells the build scripts the version to use based on the tag passed into the CI run. It should no longer try to self discover the version. Closes #13040 Signed-off-by: Matt Farina <matt@mattfarina.com> (cherry picked from commit 0b64775)
3.15.1 is out and it contains the proper version. Problem fixed. |
The text was updated successfully, but these errors were encountered: