-
Notifications
You must be signed in to change notification settings - Fork 42
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
Bug: Has a v4.0.0, but no v4 #126
Comments
There is v4 tagged ATM, only v4.0.0. Update workflows to use that instead. See Azure/setup-helm#126 Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Use azure/setup-helm ref v4.0.0 as there is yet to be a v4 release. This is due to Azure/setup-helm#126.
There seems to be a lot of confusing, can we create a new tag |
@davidgamero , @bonddim |
Generally I'd probably, as a consumer of this Action, assume that you create a tag that is more specific semver, like |
i appreciate this issue and see the confusion from this change. we can communicate the following change better in the readme, and clarify the preferred auto version upgrading strategy to reduce future confusion. something similar will be needed across other actions with this change. while there used to be a v3 and also a v3.x.x, the release action for our github actions have been upgraded now, the preferred way to auto-upgrade is using dependabot for actions which will pin the action to a hash for hardening and make PRs to upgrade instead of having a tag that we continuously delete and re-create. approving PR to remove references to the older vX scheme in the readme for clarity |
I appreciate the evident security awareness. But honestly, it's not that hard to install helm -- I used this action because it was slightly easier than running the bash script. And I think instead of agreeing with the prescription of using dependabot action bumps from a hash, which will drastically increase my daily workload of sifting through dependabot PRs if all of the Actions I consumed were to start following your pattern (usually for code dependency bumps,) I'll just move on to using the script from upstream helm, or write my own Action. Not that you should necessarily care about my opinion, this is your product. Just stating it in case it ends up happening to be the popular opinion. Fwiw, I think the security hardening you're referring to is potentially somewhat fake. We may use Dependabot to bump our Action versions each time you release an update here, but unless we're reviewing the change itself, as far as I know there's still nothing remotely protecting us against Action supply chain attacks anyway. So we traded a major release version tag for a hash that we're trusting blindly in either case, except we'll be getting more Dependabot PRs to look through for the hash. Though I agree that it's a little annoying to delete and recreate tags, it's the more convenient upgrade method for consumers, and consistently upgrading your dependencies has more obvious benefits. In closing to my argument, installing helm the normal way is less burdensome than using this Action to do it now. |
@Starttoaster Thank you for letting us know that you find the vX tags helpful. |
@davidgamero would the |
yes this one was made in the mean time, but we'll update the release action workflow to keep them updated |
@davidgamero This issue can be closed. |
Looks like |
#132 will update the release workflow to track the latest release in the major version tags. i've update v4 manually while waiting for that to merge |
v4 is automatically tracking the latest now via the action-release-worflows |
What happened?
Previous versions had a shortcut version of e.g.
v3
. The newv4
action only has av4.0.0
.This requires one to use
v4.0.0
explicitly. My expectation would be to be able to usev4
as well.Version
Runner
ubuntu-22.04
Relevant log output
None.
The text was updated successfully, but these errors were encountered: