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

Create v1 tag for rolling releases #27

Closed
pastelmind opened this issue Mar 7, 2020 · 2 comments
Closed

Create v1 tag for rolling releases #27

pastelmind opened this issue Mar 7, 2020 · 2 comments

Comments

@pastelmind
Copy link

pastelmind commented Mar 7, 2020

First, thanks for maintaining this neat GitHub Action, and congrats for the v1.1.0 release.

Now that we no longer have the alpha suffix in the version, could you please create a v1 tag which is kept updated to the latest stable version? It would greatly benefit users looking to "subscribe" to bug fixes. Also, all of GitHub's official Actions also provide a v1 tag, and it would make the overall user experience consistent when writing Workflows.

I understand that updating the v1 tag every time adds extra burden on the maintainers. Hopefully, it might be automate this as part of the release process for this Action.

@pastelmind
Copy link
Author

Looks like someone built an Action for this: Release GitHub Actions

@webknjaz
Copy link
Member

webknjaz commented Mar 7, 2020

@pastelmind thanks for your kind words!

I understand that updating the v1 tag every time adds extra burden on the maintainers

This is actually a duplicate of #22 :) And that issue suggests an automation for dealing with this boring routine.

It would greatly benefit users looking to "subscribe" to bug fixes. Also, all of GitHub's official Actions also provide a v1 tag, and it would make the overall user experience consistent when writing Workflows.

This is a good idea from the UX perspective. But from the security perspective, it's terrible (not on our side but on the side of end-users): you basically set up a moving target in your repo, forget about it and hope that it won't start pointing to some malicious code at some point in the future. There's even no tooling to protect yourself from such a treat — somebody may temporarily inject something bad into your workflows and then revert it while you won't even notice!
Ref: https://julienrenaux.fr/2019/12/20/github-actions-security-risk/.

That said, I haven't decided if it's worth implementing. It is way safer to recommend users pin versions to commit sha.

I think I'll integrate that autorelease action but will put a big red warning about using sha instead of ephemeral Git pointers...

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

No branches or pull requests

2 participants