[Nightly tests] Disable caching

[teqdruid]

Is there any particular reason we're still caching the nightly builds? I don't think there's any reason to want them running fast. It'd be nice to save the compute but if it pollutes the cache so that PR gates aren't cached I think disabling them is a net-positive on compute.

[teqdruid]

@seldridge @uenoku

[seldridge]

Yeah, I agree that we can just drop them. Or: get the subset of them that do overlap with cached "normal" builds to be cached and then share with the normal builds.

I had thought that #8580 was dropping all caching of the nightly, but it looks like it isn't.

The main thing that would help here is if we can get _all_the CI builds onto common infrastructure: same image and same configure. The unifiedBuildTestAndInstall reusable action is the closest thing to this and is unified for some of the jobs. However, I've been meaning to get everything onto this. This is missing what the docker images provide for having everything that needs to be installed available.

👍 from me.

[uenoku]

We stopped caching for debug and I think it's fine to drop release builds as well. That said cache is very effective for release and caches for nightly release builds takes only 2~3 GB per day. I think with #8580 caches for normal PRs won't be dropped anymore.

[teqdruid]

2 - 3 GB out of a 10 GB cache is quite significant...

…

On Fri, Jun 27, 2025 at 5:27 PM Hideto Ueno ***@***.***> wrote: We stopped caching for debug and I think it's fine to drop release builds as well. That said cache is very effective for release and caches for nightly release builds takes only 2~3 GB per day so I think with #8580 <#8580> caches for normal PRs won't be dropped anymore. Screenshot.2025-06-27.at.2.21.24.PM.png (view on web) <https://github.com/user-attachments/assets/5529101c-79aa-4610-bc22-912ebdf536d9> — Reply to this email directly, view it on GitHub <#8614 (comment)> or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALNXYH3TZXJSI3IJ3HB4ML3FWZNXBFKMF2HI4TJMJ2XIZLTSOBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDUOJ2WLJDOMFWWLLTXMF2GG2C7MFRXI2LWNF2HTAVFOZQWY5LFUVUXG43VMWSG4YLNMWVXI2DSMVQWIX3UPFYGLLDTOVRGUZLDORPXI6LQMWWES43TOVSUG33NNVSW45FGORXXA2LDOOJIFJDUPFYGLKTSMVYG643JORXXE6NFOZQWY5LFVEZDINJQG4ZDKMJUQKSHI6LQMWSWS43TOVS2K5TBNR2WLKRTGE4DIMBTGUZTIONHORZGSZ3HMVZKMY3SMVQXIZI> . You are receiving this email because you authored the thread. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> .

[uenoku]

After 55c3fef and ec988bb I think caches has been working much better. My point is 7-8 GB is sufficient for normal PRs once #8580 was merged. Essentially we only need 2GB for caches on main branch:

• 1GB for LLVM debug/release build
• 500MB for windows cache
• 500MB for short-integration CI

There is still some slowness slow CI in windows (https://github.com/llvm/circt/actions/runs/15925036164) but cache is restored actually.

Dropping nightly release caches might be ok but my concern is that CI queues will get stuck while nightly integration CI running (extra 30min x 8 will be consumed by release builds if we dropped caches).