@@ -108,30 +108,11 @@ jobs:
108108 with :
109109 node-version : 24
110110
111- - name : Cache Bun package cache
112- uses : actions/cache@v4
113- with :
114- path : ~/.bun/install/cache
115- key : bun-cache-${{ runner.os }}-${{ runner.arch }}-${{ hashFiles('bun.lock') }}
116- restore-keys : bun-cache-${{ runner.os }}-${{ runner.arch }}-
117-
118- # Electron's postinstall downloads a ~120MB runtime zip into this cache,
119- # and electron-builder pulls its packaging tools (nsis, winCodeSign,
120- # AppImage) into a sibling cache on first use. Both are keyed only by
121- # version, so a lockfile-keyed cache stays warm across most releases.
122- - name : Cache Electron downloads
123- uses : actions/cache@v4
124- with :
125- path : |
126- ~/Library/Caches/electron
127- ~/Library/Caches/electron-builder
128- ~/.cache/electron
129- ~/.cache/electron-builder
130- ~/AppData/Local/electron/Cache
131- ~/AppData/Local/electron-builder/Cache
132- key : electron-cache-${{ runner.os }}-${{ runner.arch }}-${{ hashFiles('bun.lock') }}
133- restore-keys : electron-cache-${{ runner.os }}-${{ runner.arch }}-
134-
111+ # No package/electron caches here on purpose: on Blacksmith's NVMe
112+ # runners a cold `bun install` (8-55s) is as fast as a cache
113+ # restore + warm install, and bun.lock changes on every release
114+ # (Version Packages), so each publish would pay the cache-save tail
115+ # (~45s on the mac critical path) for nothing.
135116 - name : Install dependencies
136117 run : bun install --frozen-lockfile
137118
0 commit comments