You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just the stable input. I don't understand what stable adds for actions/setup-go. If you only want stable builds you can set go-version accordingly. If there is good use case for stable, it can be added.
The README mentions that stable hasn't been added. I believe it would be very good to add it because it means that the workflow file can be the same without having to create a new commit (plus PR depending on the project). The same goes for using oldstable for the older maintained release. Using these two makes it possible to basically have a fire-and-forget workflow that constantly keeps updated to test with the latest supported Go versions.
Thanks for bringing this up. You can already simulate stable by setting go-version: 1.x, but I don't think there is a way to simulate oldstable. Your use case seems valid, and there doesn't seem to be a downside, so I'm inclined to add this. I'll be looking at it today, but I can't be sure when a PR will land.
As an aside, the part of the README you quoted is referencing the "stable" input as it existed in actions/setup-go@v2. v3 dropped that input and replaced it with the stable and oldstable aliases.
The README mentions that
stable
hasn't been added. I believe it would be very good to add it because it means that the workflow file can be the same without having to create a new commit (plus PR depending on the project). The same goes for usingoldstable
for the older maintained release. Using these two makes it possible to basically have a fire-and-forget workflow that constantly keeps updated to test with the latest supported Go versions.This goes hand in hand with my issue over at setup-go: actions/setup-go#450
The text was updated successfully, but these errors were encountered: