Description
The CI cache documentation still recommends forcing FileCacheStorage. However, with Rector 2.6.2, CacheFactory selects MemoryCacheStorage whenever CI is detected:
if ((new CiDetector())->isCiDetected()) {
return new Cache(new MemoryCacheStorage());
}This happens before the configured cache directory/storage can be used. As a result, a persisted GitHub Actions cache is restored successfully, but Rector does not read the cached entries in the next run.
Reproduction
Configuration:
<?php
use Rector\Caching\ValueObject\Storage\FileCacheStorage;
use Rector\Config\RectorConfig;
return RectorConfig::configure()
->withCache(
cacheClass: FileCacheStorage::class,
cacheDirectory: __DIR__.'/.rector.cache',
);GitHub Actions cache:
- name: Rector Cache
uses: actions/cache@v4
with:
path: .rector.cache
key: ${{ runner.os }}-rector-${{ github.run_id }}
restore-keys: |
${{ runner.os }}-rector-
- run: mkdir -p .rector.cache
- run: vendor/bin/rector process --dry-runThe cache action reports a successful restore, but the following Rector run behaves like a cold run and reparses the entire codebase.
Expected behavior
When FileCacheStorage is explicitly configured, Rector should use it in CI so that cache entries restored from a previous job or workflow run are reused.
Actual behavior
Rector uses MemoryCacheStorage in CI. The cache directory may be restored and populated, but the restored entries are ignored because the in-memory cache starts empty for each process.
This increases CI runtime significantly. In our Laravel application, Rector takes approximately 77 seconds in CI despite restoring the cache successfully. Locally, the same configuration drops from roughly 33 seconds on a cold run to 7.5 seconds on a warm run.
Possible fixes
One of the following would resolve the issue:
- Preserve the documented cacheClass: FileCacheStorage override and give it precedence over the CI default.
- Add an explicit supported configuration option or environment variable to enable file caching in CI.
- Update the documentation to explain that external CI caches are no longer supported and remove the GitHub Actions caching guidance.
PR rectorphp/rector-src#8311 states that an explicit cacheClass() configuration should still win, but the current CacheFactory behavior appears to select the in-memory cache before honoring that configuration in a CI.
Related PR: rectorphp/rector-src#8311
Current documentation: https://getrector.com/documentation/cache-in-ci
The strongest point is the contradiction between PR's stated compatibility promise and the current (changed) CacheFactory behavior when having an explicit configuration.
Description
The CI cache documentation still recommends forcing
FileCacheStorage. However, with Rector 2.6.2,CacheFactoryselectsMemoryCacheStoragewhenever CI is detected:This happens before the configured cache directory/storage can be used. As a result, a persisted GitHub Actions cache is restored successfully, but Rector does not read the cached entries in the next run.
Reproduction
Configuration:
GitHub Actions cache:
The cache action reports a successful restore, but the following Rector run behaves like a cold run and reparses the entire codebase.
Expected behavior
When
FileCacheStorageis explicitly configured, Rector should use it in CI so that cache entries restored from a previous job or workflow run are reused.Actual behavior
Rector uses
MemoryCacheStoragein CI. The cache directory may be restored and populated, but the restored entries are ignored because the in-memory cache starts empty for each process.This increases CI runtime significantly. In our Laravel application, Rector takes approximately 77 seconds in CI despite restoring the cache successfully. Locally, the same configuration drops from roughly 33 seconds on a cold run to 7.5 seconds on a warm run.
Possible fixes
One of the following would resolve the issue:
PR rectorphp/rector-src#8311 states that an explicit
cacheClass()configuration should still win, but the currentCacheFactorybehavior appears to select the in-memory cache before honoring that configuration in a CI.Related PR: rectorphp/rector-src#8311
Current documentation: https://getrector.com/documentation/cache-in-ci
The strongest point is the contradiction between PR's stated compatibility promise and the current (changed)
CacheFactorybehavior when having an explicit configuration.