If you liked this blog post, you may enjoy the book “English and American Tool Builders" by Joseph Wickham Roe.

    -- fails if any rows exist in the table since the new column
    -- is not null and also has no default value.
    ALTER TABLE users ADD COLUMN status text NOT NULL;

I bring this up not because it's a gotcha but because I wonder how you think about the utility of rules-based classifiers like this. At a certain point, if you need to extend your rules engines with tons of edge cases like this, why not just ask a true LLM? Or, have you considered extending your default ruleset with generated rules — maybe point an LLM at use-the-index, other db docs, or just ask it to expand the ruleset based on its own knowledge?

Reasonable suggestions, but we've mostly published our action as reference for others. I'd suggest forking or creating your own setup-go action and implementing whatever behavior you'd like. Nothing wrong with either idea!

- Allowing actions/setup-go users to specify a cache key prefix so that they can have more than one golang CI job, each with its own cache: this is 100% worth upstreaming. I believe there are existing requests and PRs about this. Up to you guys to implement however you see fit.

- Allowing "always update the cache": also a good idea to enable as an option, very important for non-open-source teams that are trying to maximize cache hit rate.

- Allowing "trim the cache": if you're going to allow always updating the cache, probably a good idea.

But the "always update" and "trim" cache changes combine to have a lot of risks regarding cache poisoning that might be bad for open source projects. Lukas may have a different opinion or more to say on this front.

- This post

- The DeepMind Institute https://news.ycombinator.com/item?id=49727659

- Mistral X Mozilla: Private, Multilingual AI Browsing https://news.ycombinator.com/item?id=49723408

based on their account submission history they have a 25% hit rate (!) Seems very, very weird.

- Our approach writes new cache entries all the time. This can get expensive, and is a pretty big change in behavior from how actions/setup-go works today.

- actions/setup-go can basically be considered incredibly critical infrastructure for the public golang ecosystem. Any change in behavior is probably very risky and slow to happen. At this point I'd bet that we see no change, ever, in behavior.

Additionally there are a few relevant issues/prs that have been ignored for years so I'm not optimistic about contributing upstream. Frankly what we've done is write a very small bit of glue code that is likely most effective as a reference for teams writing their own custom caching actions that fit their exact needs:

- https://github.com/actions/setup-go/pull/426

- https://github.com/actions/setup-go/issues/630

- https://github.com/actions/setup-go/issues/395

- https://github.com/actions/setup-go/issues/596

That said we'd be happy if someone used our code and found it valuable! Lukas put a ton of effort into cleaning up my initial version, added the cache trimming, etc. We depend on this for all of our jobs and use it every day and think it's quite good.

The blogpost has a lot of technical details, but you can also just read the code and try it yourself:

https://github.com/cloudx-io/setup-go

Comments URL: https://news.ycombinator.com/item?id=49726350

Points: 77

# Comments: 26

I HATE that this is somehow becoming a culture war issue.

Some confusion in the threads below —

pgtestdb is just a primitive for “give my test a clean db, fast.” With your postgres running on ramdisk, I don’t think there’s any faster way to make a clean and fully migrated db — and your migrations only run one time, no matter how many test processes you have operating concurrently or how many tests are in parallel within those processes.

You can actually combine it with test transactions, you’re totally allowed to do anything you want with the db! It just so happens that it’s fast enough (in my experience) to Just Give Every Test Its Own Database, for quite a large number of tests.

Really cool upside of AI is enabling experiments like this one that previously would have been prohibitively time consuming. Thanks again, Brandur.