CI: benchmark pip cache reuse

[vyasr]

Description

Temporary control for measuring pip-cache impact.

Checklist

• I am familiar with the Contributing Guidelines.
• New or existing tests cover these changes.
• The documentation is up to date with these changes (temporary CI benchmark).

[copy-pr-bot]

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

[vyasr]

/ok to test

[vyasr]

/ok to test

[vyasr]

/ok to test

[vyasr]

/ok to test

[vyasr]

/ok to test

[vyasr]

Intra-job pip-cache results

I compared the clean full-CI baseline (run 34388028288) with the cache-enabled run (run 34396369088). The latter uses the SHA-pinned rapids-init-pip prototype for every direct caller, without any actions/cache pip configuration.

The cache is working: a completed pandas job reports PIP_CACHE_DIR=/__w/cudf/cudf/.cache/pip and later pip invocations report Using cached for dependency metadata and wheels.

Job family	Baseline avg.	Intra-job cache avg.	Delta
wheel C++ builds	435.8 s	419.3 s	-16.5 s
wheel Python builds	343.3 s	340.8 s	-2.5 s
wheel noarch builds	247.0 s	243.0 s	-4.0 s
wheel-cuDF tests	751.8 s	770.6 s	+18.9 s
wheel-cuDF-Polars tests	736.5 s	768.5 s	+32.0 s
pandas shards	1528.5 s	1556.5 s	+28.0 s
Narwhals	217.0 s	210.0 s	-7.0 s

The full runs have the same substantive failures: the two unavailable devcontainer pip images and the optional third-party pandas-integration job. The cache is functioning, but this broad comparison does not show a measurable end-to-end benefit beyond normal runner/test variance. The next useful question is which jobs actually make multiple pip invocations within one container.

[vyasr]

The primary purpose of this PR was to test rapidsai/gha-tools#277. That PR is now merged, so we no longer need this one.