Bug: Has a v4.0.0, but no v4 about setup-helm HOT 13 CLOSED

There seems to be a lot of confusing, can we create a new tag v4?

• #127
• #129

from setup-helm.

@davidgamero , @bonddim
Any particular reason why we created v4.0.0, not v4?
Can we create a new tag v4 please?

from setup-helm.

yes this one was made in the mean time, but we'll update the release action workflow to keep them updated

from setup-helm.

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.

from setup-helm.

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

from setup-helm.

@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.

from setup-helm.

created https://github.com/Azure/setup-helm/releases/tag/v4

from setup-helm.

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.

from setup-helm.

@davidgamero would the v4 tag be auto-updated for each release? (the v4.0.0 was created via GitHub Actions)

from setup-helm.

@davidgamero This issue can be closed.

from setup-helm.

Looks like v4 is already outdated. v4.1.0 is already out, but v4 still points to v4.0.0.

from setup-helm.

#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

from setup-helm.

v4 is automatically tracking the latest now via the action-release-worflows

from setup-helm.