[maccard]

> If your CI can do things that you can't do locally: that is a problem.

IME this is where all the issues lie. Our CI pipeline can push to a remote container registry, but we can't do this locally. CI uses wildly different caching strategies to local builds, which diverges. Breaking up builds into different steps means that you need to "stash" the output of stages somewhere. If all your CI does is `make test && make deploy` then sure, but when you grow beyond that (my current project takes 45 minutes with a _warm_ cache) you need to diverge, and that's where the problems start.

[tracker1]

Ironically, at least for a couple recent projects... just installing dependencies fresh is as fast on GH Actions as the GH caching methods, so I removed the caching and simplified the workflows.

[marksomnian]

In fact, uv's docs half-suggest this:

> With uv, it turns out that it's often faster to omit pre-built wheels from the cache (and instead re-download them from the registry on each run). On the other hand, caching wheels that are built from source tends to be worthwhile, since the wheel building process can be expensive, especially for extension modules.

https://docs.astral.sh/uv/concepts/cache/#caching-in-continu...

[maccard]

On the projects we work on, we don’t use ephemeral workers and we rely on tool chains for incremental builds. It’s flakier but 100x faster…