mirror of
https://github.com/pchuan98/codex.git
synced 2026-07-01 00:31:56 +08:00
Michael Bolin
fffc92a779
## Why `rust-release` cache restore has had very low practical value, while cache save consistently costs significant time (usually adding ~3 minutes to the critical path of a release workflow). From successful release-tag runs with cache steps (`289` runs total): - Alpha tags: cache download averaged ~5s/run, cache upload averaged ~230s/run. - Stable tags: cache download averaged ~5s/run, cache upload averaged ~227s/run. - Windows release builds specifically: download ~2s/run vs upload ~169-170s/run. Hard step-level signal from the same successful release-tag runs: - Cache restore (`Run actions/cache`): `2,314` steps, total `1,515s` (~0.65s/step). - `95.3%` of restore steps finished in `<=1s`; `99.7%` finished in `<=2s`; `0` steps took `>=10s`. - Cache save (`Post Run actions/cache`): `2,314` steps, total `66,295s` (~28.65s/step). Run-level framing: - Download total was `<=10s` in `288/289` runs (`99.7%`). - Upload total was `>=120s` in `285/289` runs (`98.6%`). The net effect is that release jobs are spending time uploading caches that are rarely useful for subsequent runs. ## What Changed - Removed the `actions/cache@v5` step from `.github/workflows/rust-release.yml`. - Removed the `actions/cache@v5` step from `.github/workflows/rust-release-windows.yml`. - Left build, signing, packaging, and publishing flow unchanged. ## Validation - Queried historical `rust-release` run/job step timing and compared cache download vs upload for alpha and stable release tags. - Spot-checked release logs and observed repeated `Cache not found ...` followed by `Cache saved ...` patterns.
fffc92a779
ยท
2026-02-11 20:49:26 -08:00
History
