While parsing your application code, Rector generates objects representing that code. It caches these objects for later reuse, so it doesn't have to parse the entire application again, by detecting which files have changed since the last Rector run.
When running Rector in a Continuous Integration (CI) system such as GitHub Actions, the default implementation uses an in-memory cache. This means the next job that runs, will have to parse all code from scratch.
<?php
use Rector\Caching\ValueObject\Storage\FileCacheStorage;
use Rector\Config\RectorConfig;
return RectorConfig::configure()
->withCache(
// ensure file system caching is used instead of in-memory
cacheClass: FileCacheStorage::class,
// specify a path that works locally as well as on CI job runners
cacheDirectory: '/tmp/rector'
);
Note that this caches relative to the repository directory, so it's the same directory on build as on development (and other environments). The actual path, when not specified, may vary per (runner) OS.
Generate the cache on your development machine, by running the command:
vendor/bin/rector process --dry-run
You can find it in /tmp/rector, containing folders like 0a, 0b, 0c, ... containing the cache objects representing the latest run.
This, preferably prepended with php , command is also what your CI action should run, after mapping the cache directory from an earlier run.
On GitHub Actions, you can use the built-in cache action as a step to point to a path that you want cached between jobs:
- name: Rector Cache
uses: actions/cache@v4
with:
path: /tmp/rector
key: ${{ runner.os }}-rector-${{ github.run_id }}
restore-keys: ${{ runner.os }}-rector-
- run: mkdir -p /tmp/rector
- name: Rector Dry Run
run: php vendor/bin/rector process --dry-run --config=rector.php
In this key configuration, runs on branches inherit the cache from their parent, if any.
