We recently did similar work for our pipelines, heavily based on Better GitHub Actions caching for Go [0]. Were you aware of that article, or did you (re-)discover things like the cache trimming?
What's the best way to contribute? I'd like to expose the "go-version-file" input for the setup-go action instead of setting a Go version directly. Open an issue in the repo?
Also, have you considered this potential optimization: the module cache doesn't care about architecture, it's just downloaded code. Would it make sense to cache module and build cache separately, and use an architecture-free cache key for the module cache?
lol, true! Even for a single side project, that probably no one is gonna use, I often struggle for hours while choosing a name, meanwhile these folks...
The `|| true` is often done because people use `errexit` as part of "Bash strict mode"[1], which comes with so many caveats[2] that I usually avoid it. Claude, however, loves it.
I use "strict mode" in almost every script I write. IMO these caveats shouldn't be a reason not to use it, but should instead be used as a manual of what to avoid when using it. This is just programming. Everything is a tradeoff.
`|| true` is a horrible practice because even though it may help in cases where a specific failure mode is acceptable, it obscures unexpected failures and could prove catastrophic. The solution is not to drop the protections but rather to handle the expected failure and let the sript crash otherwise.
This is, again, programming. You don't usually `catch Exception` in Python for similar reasons. There may be legitimate uses for that, but IME they are a rare exception and realistically only used when I actually don't care about what happens when I run it.
The other infuriating thing I found is that when I call out the model for its use of `|| true`, it tends to replace them with `|| echo "error foobar"` - which is at least not completely silent but the same problems exist.
Yes there's no Opus at all on Pro. GPT 5.5 is also missing. Then again what would you expect, the economic reality is beginning to hit. Also I can't be too mad when the "base" models (GPT 5.4...) are still available and decent.
When I see how fast Codex max thinking GPT 5.5 eats our enterprise seat credits almost anything else seems cheap (until we switch our live systems from 5.4 api to 5.5 api I guess)... good thing I'm not the one paying for those credits and tokens (which is probably how most of the money is going to be made on AI going forward, borderline free chatbots for normies are done)
I just want the simple feature of PRs updating when the target branch changes. For example, say I have two tickets: T-100 and T-101. Both are targeting main, but T-101 builds on top of T-100. I put up a PR for the T-100 branch against main, and put up a PR for the T-101 branch against main.
The T-101 PR can't really be reviewed yet, since you are looking at changes from both T-100 and T-101 (because T-101 was based on T-100).
Ideally, after T-100 is reviewed and merged, the T-101 PR would automatically update to show only the T-101 changes. But it doesn't. You have to manually rebase or merge main and push changes to the branch to get it to update. It would be great if GitHub handled this automatically.
What's the best way to contribute? I'd like to expose the "go-version-file" input for the setup-go action instead of setting a Go version directly. Open an issue in the repo?
Also, have you considered this potential optimization: the module cache doesn't care about architecture, it's just downloaded code. Would it make sense to cache module and build cache separately, and use an architecture-free cache key for the module cache?
[0]: https://danp.net/posts/github-actions-go-cache/
reply