[dijit]

I mean, at some point you are bash calling some other language anyway.

I'm a huge fan of "train as you fight", whatever build tools you have locally should be what's used in CI.

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

[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…

[embedding-shape]

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

Probably most of the times when this is an actual problem, is building across many platforms. I'm running Linux x86_64 locally, but some of my deliverables are for macOS and Windows and ARM, and while I could cross-compile for all of them on Linux (macOS was a bitch to get working though), it always felt better to compile on the hardware I'm targeting.

Sometimes there are Windows/macOS-specific failures, and if I couldn't just ssh in and correct/investigate, and instead had to "change > commit > push" in an endless loop, it's possible I'd quite literally would lose my mind.

[ethin]

I literally had to do this push > commit > test loop yesterday because apparently building universal Python wheels on MacOS is a pain in the ass. And I don't have a mac, so if I want to somewhat reliably reproduce how the runner might behave, I have to either test it on GH actions or rent one from something like Scaleway. Mainly because I don't currently knwo how else to do it. It's so, so frustrating and if anyone has ideas on making my life a bit better that would be nice lol.

[Imustaskforhelp]

there is quickemu which can install mac vm on linux (or any other host) rather quickly, what are your thoughts on it (I am an absolute quickemu shill because I love that software)

https://github.com/quickemu-project/quickemu [ Quickly create and run optimised Windows, macOS and Linux virtual machines ]

[tracker1]

Thank you so much for this... If I could +1 a dozen times I would.

[Imustaskforhelp]

Thanks! Glad I could help. If I may ask, what specific use case are you using quickemu for? Is it also for running mac machines on say linux?

[tracker1]

That's what I intend to use it for, Mac and Windows... I'm starting on an app that I want to work cross platform (tauri/rust w/ react+mui) and want to be able to do manual testing or troubleshooting as needed on mac and windows without needing a separate machine.

My laptop is an M1 MacBook Air, and I do have an N100 I could use for Windows... I'd just assume use my fast desktop which even emulated is likely faster and not have to move seats.

[Storment33]

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

Completely agree.

> I'm a huge fan of "train as you fight", whatever build tools you have locally should be what's used in CI.

That is what I am doing, having my GitHub Actions just call the Make targets I am using locally.

> I mean, at some point you are bash calling some other language anyway.

Yes, shell scripts and or task runners(Make, Just, Task etc) are really just plumbing around calling other tools. Which is why it feels like a smell to me when you need something more.