Cache in CI

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.


use Rector\Caching\ValueObject\Storage\FileCacheStorage;
use Rector\Config\RectorConfig;

return RectorConfig::configure()
        // 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.

Debugging the Cache Locally

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.

GitHub Actions

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@v3
          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.