Closed ctron closed 6 months ago
There seems to be a lot of confusing, can we create a new tag v4
?
@davidgamero , @bonddim
Any particular reason why we created v4.0.0, not v4
?
Can we create a new tag v4
please?
Generally I'd probably, as a consumer of this Action, assume that you create a tag that is more specific semver, like v4.0.0
and a v4
tag. So the answer, I would assume, to "Any particular reason why we created v4.0.0, not v4?" is because half of the job on release was done, but the other half was missing.
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. We want to contribute to your productivity and don't aim to add additional hurdles unless absolutely necessary. With that spirit, we will add the vX tags again accompanied with the recommendation that hashes be pinned when actions are used.
@davidgamero would the v4
tag be auto-updated for each release? (the v4.0.0
was created via GitHub Actions)
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 v4
is already outdated. v4.1.0
is already out, but v4
still points to v4.0.0
.
https://github.com/Azure/setup-helm/pull/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.