Skip to content
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

Closed
1 task done
ctron opened this issue Feb 13, 2024 · 13 comments
Closed
1 task done

Bug: Has a v4.0.0, but no v4 #126

ctron opened this issue Feb 13, 2024 · 13 comments
Labels
bug Something is not working

Comments

@ctron
Copy link

ctron commented Feb 13, 2024

What happened?

Previous versions had a shortcut version of e.g. v3. The new v4 action only has a v4.0.0.

This requires one to use v4.0.0 explicitly. My expectation would be to be able to use v4 as well.

Version

  • I am using the latest version

Runner

ubuntu-22.04

Relevant log output

None.

@ctron ctron added the bug Something is not working label Feb 13, 2024
klihub added a commit to klihub/nri-plugins that referenced this issue Feb 14, 2024
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>
nitschSB added a commit to nitschSB/evryfs-helm-charts that referenced this issue Feb 15, 2024
d3adb5 added a commit to d3adb5/helm-unittest-action that referenced this issue Feb 20, 2024
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.
@nilfr
Copy link

nilfr commented Feb 21, 2024

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

@hangai247
Copy link

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

@Starttoaster
Copy link

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.

@davidgamero
Copy link
Collaborator

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

@Starttoaster
Copy link

Starttoaster commented Feb 27, 2024

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.

@davidgamero
Copy link
Collaborator

davidgamero commented Feb 28, 2024

@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
Copy link
Collaborator

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

@bxsx
Copy link

bxsx commented Feb 28, 2024

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

@davidgamero
Copy link
Collaborator

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

@nilfr
Copy link

nilfr commented Feb 29, 2024

@davidgamero This issue can be closed.

@SpecLad
Copy link

SpecLad commented Mar 6, 2024

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

@davidgamero
Copy link
Collaborator

#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

@davidgamero
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something is not working
Projects
None yet
Development

No branches or pull requests

7 participants