Version: 2.7.0
Problem
Each test_sim / test_* run stages a full .xctestproducts bundle (a Binaries/ copy of the built test products) under ~/Library/Developer/XcodeBuildMCP/workspaces/<workspace>/test-products/. In one of the repos I work on, each bundle is ~6.6 GB.
pruneManagedTestProductsDirectory only removes bundles that are either:
- older than 3 days (
TEST_PRODUCTS_MAX_AGE_MS), or
- in excess of 100 retained (
TEST_PRODUCTS_MAX_COUNT),
and the sweep only runs while the server is active (1h cooldown). At ~6.6 GB/bundle that permits roughly 660 GB before count-based GC ever triggers. In practice, 20 runs over two days silently consumed 66 GB and contributed to filling my disk.
Root cause
These limits are hardcoded in utils/test-products-lifecycle.js:
const TEST_PRODUCTS_MAX_AGE_MS = 3 * 24 * 60 * 60 * 1e3;
const TEST_PRODUCTS_MAX_COUNT = 100;
and the caller in utils/workspace-filesystem-lifecycle.js only ever passes maxAgeMs (the log max-age, also 3 days) — never maxCount. There is no env/config surface to tune count, age, or a total-size cap, unlike XCODEBUILDMCP_DERIVED_DATA_PATH for derived data.
Request
Expose retention controls, e.g.:
XCODEBUILDMCP_TEST_PRODUCTS_MAX_COUNTXCODEBUILDMCP_TEST_PRODUCTS_MAX_AGEXCODEBUILDMCP_TEST_PRODUCTS_MAX_TOTAL_BYTES
and/or lower the defaults given bundles are multi-GB (e.g. keep only the newest N per workspace). A total-size budget would be the most robust guard against filling the disk between the age/count thresholds.
Version: 2.7.0
Problem
Each
test_sim/test_*run stages a full.xctestproductsbundle (aBinaries/copy of the built test products) under~/Library/Developer/XcodeBuildMCP/workspaces/<workspace>/test-products/. In one of the repos I work on, each bundle is ~6.6 GB.pruneManagedTestProductsDirectoryonly removes bundles that are either:TEST_PRODUCTS_MAX_AGE_MS), orTEST_PRODUCTS_MAX_COUNT),and the sweep only runs while the server is active (1h cooldown). At ~6.6 GB/bundle that permits roughly 660 GB before count-based GC ever triggers. In practice, 20 runs over two days silently consumed 66 GB and contributed to filling my disk.
Root cause
These limits are hardcoded in
utils/test-products-lifecycle.js:and the caller in
utils/workspace-filesystem-lifecycle.jsonly ever passesmaxAgeMs(the log max-age, also 3 days) — nevermaxCount. There is no env/config surface to tune count, age, or a total-size cap, unlikeXCODEBUILDMCP_DERIVED_DATA_PATHfor derived data.Request
Expose retention controls, e.g.:
XCODEBUILDMCP_TEST_PRODUCTS_MAX_COUNTXCODEBUILDMCP_TEST_PRODUCTS_MAX_AGEXCODEBUILDMCP_TEST_PRODUCTS_MAX_TOTAL_BYTESand/or lower the defaults given bundles are multi-GB (e.g. keep only the newest N per workspace). A total-size budget would be the most robust guard against filling the disk between the age/count thresholds.