https://github.com/boringcache/benchmark-spring-ai
Standalone Spring AI benchmark runner for BoringCache vs GitHub Actions cache
https://github.com/boringcache/benchmark-spring-ai
Last synced: about 1 month ago
JSON representation
Standalone Spring AI benchmark runner for BoringCache vs GitHub Actions cache
- Host: GitHub
- URL: https://github.com/boringcache/benchmark-spring-ai
- Owner: boringcache
- Created: 2026-03-17T15:50:19.000Z (3 months ago)
- Default Branch: main
- Last Pushed: 2026-05-10T21:45:34.000Z (about 1 month ago)
- Last Synced: 2026-05-10T23:31:50.572Z (about 1 month ago)
- Language: Shell
- Size: 72.3 KB
- Stars: 0
- Watchers: 0
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# benchmark-spring-ai
Public Spring AI Maven benchmark runner for BoringCache vs GitHub Actions cache.
This repo exists separately from [`boringcache/benchmarks`](https://github.com/boringcache/benchmarks) so the benchmark keeps:
- one pinned upstream source commit
- isolated GitHub Actions cache usage
- one per-repo BoringCache workspace name: `boringcache/benchmark-spring-ai`
- independent workflow history plus upstream-sync-driven benchmark runs and manual dispatches
## Source Model
- Upstream source lives in the pinned `upstream/` submodule.
Pinned upstream source:
- see committed `upstream/` submodule on `main`
## What It Measures
Fresh lane runs a no-prior-cache cold build plus one warm rerun for each backend:
- `cold`
- `warm1`
Rolling lane records the upstream commit build as-is after each upstream sync against the prior rolling cache and intentionally skips `warm1`.
The story this benchmark is meant to show is:
- speed on fresh cold and warm paths
- commit-build behavior on normal upstream syncs in the rolling lane
- storage footprint in each backend
- cache reuse through native Maven remote-cache behavior
## Token Model
This repo uses split BoringCache tokens as the standard CI shape:
- `BORINGCACHE_RESTORE_TOKEN` for read-only restore and proxy access
- `BORINGCACHE_SAVE_TOKEN` for trusted write paths
- `BORINGCACHE_API_TOKEN` only where a single bearer variable is still required for compatibility