Skip to content
Latchkey

Wrong PHP Version in CI - Pin the Interpreter

Your job is running on a different PHP than you think. Newer syntax fails on an old interpreter, or a dependency rejects the version, because the runner inherited whatever PHP the image ships by default.

What this error means

Code that works locally fails in CI with a parse error for a feature your version supports, or Composer rejects a package on a version constraint. php -v in CI prints something other than what you intended.

CI log
$ php -v
PHP 8.0.30 (cli)
$ php bin/console
PHP Parse error: syntax error, unexpected token "enum" in src/Status.php on line 5

Common causes

The image default PHP is not what you assumed

The runner image’s default php may be older (or newer) than your code requires. Without pinning, you inherit the image default.

setup-php missing or shadowed

If the setup-php step is absent, or a later PATH change shadows it, the php in use is not the one you configured.

How to fix it

Pin the PHP version explicitly

.github/workflows/ci.yml
- uses: shivammathur/setup-php@v2
  with:
    php-version: '8.3'
- run: php -v   # assert it's what you expect

Test a matrix of versions

If you support several PHP versions, run them all so a version-specific break is caught.

.github/workflows/ci.yml
strategy:
  matrix:
    php-version: ['8.1', '8.2', '8.3']

How to prevent it

  • Always pin the PHP version in CI; never rely on the image default.
  • Add an early php -v assertion step.
  • Keep the CI matrix aligned with the PHP versions you actually support.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →