Test-products retention is unbounded in practice (100 bundles / 3 days, no config knob) — can fill a disk

まず utils/test-products-lifecycle.js を読み、pruneManagedTestProductsDirectory とその TEST_PRODUCTS_MAX_AGE_MS および TEST_PRODUCTS_MAX_COUNT 定数を確認してから、utils/workspace-filesystem-lifecycle.js の呼び出し元を追跡します。保持設定をどのように公開すべきか、また合計サイズの制限と個数/経過時間の制限がどのように相互作用すべきかを判断します。完了の定義は、設定可能なクリーンアップによって文書化されたディスク増大シナリオを防ぎ、既存のライフサイクル動作が引き続きカバーされることです。

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_COUNT
• XCODEBUILDMCP_TEST_PRODUCTS_MAX_AGE
• XCODEBUILDMCP_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.