Skip to content

feat: keep the Go build cache under a size limit, as lanes start - #1447

Queued
REPPL wants to merge 1 commit into
mainfrom
build/run-2611070737217912-lane-1
Queued

REPPL wants to merge 1 commit into
mainfrom
build/run-2611070737217912-lane-1

Conversation

@REPPL

@REPPL REPPL commented Nov 7, 2026

Copy link
Copy Markdown
Collaborator
  • feat: keep the Go build cache under a size limit, as lanes start

Resolves: iss-2611041338455722
Assisted-by: abcd:dev
Assisted-by: Claude:claude-opus-5-5

An age does not bound the cache: one held 324 GB with every entry used
within five days, so a two-day trim freed 87 GB. The trim now deletes the
oldest entries until the rest fit a limit, 100 GiB by default and set only
in the person's own configuration, keeping anything used in the last 3
hours and saying so when those alone exceed it. A cache under its limit
loses nothing to age.

Prune is too rare on a machine that goes days without one and the load
gate only refuses, so the build loop starts the trim detached when it makes
a lane, at most once an hour across the account. A new verb, ahoy worktree
trim-cache, is what it runs and what the gate's refusal now offers. The
lane does not wait; the next lane says on stderr what a detached run could
not do. Prune's JSON drops unused_days for the limit and the sizes.

Resolves: iss-2611041338455722
Assisted-by: Claude:claude-opus-5-5
@REPPL
REPPL enabled auto-merge November 7, 2026 15:13
@REPPL
REPPL added this pull request to the merge queue Nov 7, 2026
Any commits made after this event will not be merged.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant