2 ms·

Correct, but it's been ages and the default actions/setup-go github action still uses go.sum instead. I see that someone already commented on the longstanding i

Correct, but it's been ages and the default actions/setup-go github action still uses go.sum instead. I see that someone already commented on the longstanding issue to reference this post, and that there is some hope that they'll update it! https://github.com/actions/setup-go/issues/478 https://github.com/actions/setup-go/issues/478

Groxx 9mo ago
The private repo mention in the comments there is kinda a good one, unfortunately. If someone runs a private gosum/goproxy (relatively common) and amends a tag (hopefully very uncommon but I have personally seen it happen at least three times) then the cache could be wrong because go.mod didn't have to change. Which is Bad™ but it depends on what edge cases they want to handle automatically, vs optimization for the majority case. For well-behaving/stable/consistent setups I fully agree though, go.mod is both sufficient and better, and those other cases can probably just key off both instead. I think I've seen go.mod to change without go.sum changes (change an unused transitive dependency into a direct dependency), which can lead to your build needing something that wasn't cached because it was pruned in the previous version.
- saghm 9mo ago
  From a relatively naive outside perspective, it sounds like this would be pretty much only ever a self-inflicted probably (where "self" might be an org rather than an individual). What you're describing sounds almost like a force push to a private repo; if you're doing that, you might break things for anyone using it, so the risks should probably rest with you for asking so. "This breaks my setup if I modify history in a way that's expected to be immutable" isn't a super compelling argument for everyone behaving well to have to continue dealing with a suboptimal status quo.
  - Groxx 9mo ago
    It's basically a force-push, yeah. Which does happen, like with git, so you do kinda need a way to deal with it even if it's not automatic. Which it sounds like they have (planned), which seems like a good improvement.
majewsky 9mo ago
At this point I'm just assuming that all of the official actions under https://github.com/actions https://github.com/actions are unmaintained garbage until proven otherwise, given that high-impact issues like this can sit for years without as much as an initial triage: https://github.com/actions/delete-package-versions/issues/162 https://github.com/actions/delete-package-versions/issues/16...

Groxx 9mo ago

The private repo mention in the comments there is kinda a good one, unfortunately. If someone runs a private gosum/goproxy (relatively common) and amends a tag (hopefully very uncommon but I have personally seen it happen at least three times) then the cache could be wrong because go.mod didn't have to change. Which is Bad™ but it depends on what edge cases they want to handle automatically, vs optimization for the majority case. For well-behaving/stable/consistent setups I fully agree though, go.mod is both sufficient and better, and those other cases can probably just key off both instead. I think I've seen go.mod to change without go.sum changes (change an unused transitive dependency into a direct dependency), which can lead to your build needing something that wasn't cached because it was pruned in the previous version.

saghm 9mo ago
From a relatively naive outside perspective, it sounds like this would be pretty much only ever a self-inflicted probably (where "self" might be an org rather than an individual). What you're describing sounds almost like a force push to a private repo; if you're doing that, you might break things for anyone using it, so the risks should probably rest with you for asking so. "This breaks my setup if I modify history in a way that's expected to be immutable" isn't a super compelling argument for everyone behaving well to have to continue dealing with a suboptimal status quo.
- Groxx 9mo ago
  It's basically a force-push, yeah. Which does happen, like with git, so you do kinda need a way to deal with it even if it's not automatic. Which it sounds like they have (planned), which seems like a good improvement.

majewsky 9mo ago

At this point I'm just assuming that all of the official actions under https://github.com/actions https://github.com/actions are unmaintained garbage until proven otherwise, given that high-impact issues like this can sit for years without as much as an initial triage: https://github.com/actions/delete-package-versions/issues/162 https://github.com/actions/delete-package-versions/issues/16...