Shocm's Blog
• 5 min read

Test Your App on PHP 8.6 RC3 Today with Docker and GitHub Actions

PHP 8.6 is in release candidate stage with GA planned for November 19. Here is how to run your tests against it with Docker and a CI matrix job now.

php php-86 docker ci testing tips

PHP 8.6 is in its release candidate phase. According to PHP.Watch’s release list, RC3 is the latest build and general availability is scheduled for November 19, 2026. Feature freeze is over, so what you test now is what ships. If a deprecation notice or a behavior change is going to break your app, October is the cheapest time to find out.

This post is a practical setup: a throwaway Docker run for a quick check, a Composer flag that gets past version constraints, and a CI job that is allowed to fail without blocking your pipeline. Nothing here needs a PHP 8.6 install on your machine.

Why bother testing a release candidate

A release candidate is meant for testing, not production. PHP.Watch states this directly on its releases page. The value is in catching problems while the core team can still fix them. A bug report filed against an RC has a real chance of being addressed before 8.6.0. One filed after GA waits for 8.6.1.

The RC3 round was described in Warp2Search’s roundup as bug fixes and memory-safety corrections only, with no new features. That is a good sign for stability, but it also means the language surface is frozen. Anything new you want to try, like partial function application or clamp(), is already in.

Step 1: Run your suite in a disposable container

The official Docker image publishes a rolling 8.6-rc tag, which Docker Hub lists as an alias for 8.6-rc-cli. Mount your project and run Composer and your test runner inside it:

docker run --rm -it \
  -v "$PWD":/app -w /app \
  php:8.6-rc-cli \
  php -v

The official image has no Composer, so copy it in from the Composer image. This keeps everything in one command:

docker run --rm -it \
  -v "$PWD":/app -w /app \
  -v composer-cache:/tmp/composer-cache \
  -e COMPOSER_CACHE_DIR=/tmp/composer-cache \
  php:8.6-rc-cli sh -c '
    apt-get update -qq && apt-get install -y -qq git unzip >/dev/null &&
    curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer &&
    composer install --ignore-platform-req=php+ &&
    vendor/bin/phpunit
  '

You will almost certainly need extensions your app uses, such as pdo_mysql, intl, or zip. The official image ships with a helper for that: docker-php-ext-install pdo_mysql intl zip. For anything more involved, build a small Dockerfile instead of a one-liner, so the image layers cache between runs.

Step 2: Get past the PHP version constraint

Most packages declare "php": "^8.2" or similar. Composer will refuse to install on 8.6 only if a package caps its version range. The flag --ignore-platform-req=php+ tells Composer to ignore the upper bound of the PHP requirement while still enforcing the lower bound. That is exactly what you want for RC testing: you keep the floor check, and you skip the cap.

If one dependency fails on 8.6, you now have a concrete signal. Check its issue tracker. A fix may already be merged, or you may be the first to report it. Do not commit the ignore flag to your lockfile workflow. It belongs in the experimental CI job only.

Step 3: Add a non-blocking CI job

Here is a GitHub Actions workflow that runs your normal matrix and adds PHP 8.6 as an experimental entry. The continue-on-error setting keeps a failing 8.6 job from turning your whole pipeline red:

name: tests

on: [push, pull_request]

jobs:
  tests:
    runs-on: ubuntu-latest
    continue-on-error: ${{ matrix.experimental }}
    strategy:
      fail-fast: false
      matrix:
        php: ['8.4', '8.5']
        experimental: [false]
        include:
          - php: '8.6'
            experimental: true
    steps:
      - uses: actions/checkout@v4

      - uses: shivammathur/setup-php@v2
        with:
          php-version: ${{ matrix.php }}
          coverage: none

      - name: Install dependencies
        run: |
          if [ "${{ matrix.experimental }}" = "true" ]; then
            composer install --ignore-platform-req=php+ --no-interaction
          else
            composer install --no-interaction
          fi

      - name: Run tests
        run: vendor/bin/phpunit

One caveat on setup-php. Release notes for v2.36.0 reportedly added 8.6 as a nightly build from php-src master, but I could not confirm the current behavior from a 2026 source. Check the setup-php README for how 8.6 is resolved today. If it gives you a nightly rather than the RC, that is still useful, though the code may be slightly ahead of RC3. If it does not work, run the job in a container instead:

    container: php:8.6-rc-cli

Step 4: Make deprecations loud

A passing suite can hide trouble. PHP 8.6 adds deprecations, and by default they are notices in a log, not failures. PHPUnit lets you turn them into failures for the experimental job. In phpunit.xml:

<phpunit
    failOnDeprecation="true"
    failOnWarning="true"
    displayDetailsOnTestsThatTriggerDeprecations="true"
>

For the Docker run or CI job, also raise error reporting so nothing is swallowed:

php -d error_reporting=-1 -d display_errors=1 vendor/bin/phpunit

If you want to know what is coming, my earlier post on PHP 8.6 deprecations and a token-based scanner covers the list and a script to find usage in your own code.

What to look for in the results

Sort failures into three buckets. First, deprecations in your own code. These are yours to fix and usually mechanical. Second, failures inside vendor packages. Search the package’s issues, and if there is nothing, open one with a minimal reproduction and the exact RC version from php -v. Third, failures that look like engine bugs: crashes, segfaults, or behavior that contradicts the documentation. Those belong on the php-src issue tracker, with the smallest script that reproduces the problem.

Pin the version in your report. The RC tags move, and 8.6-rc will become a newer RC or GA image without notice. Quote the output of php -v and the Docker image digest so maintainers can reproduce what you saw.

A short schedule

You have roughly five weeks. A reasonable plan is to add the experimental job this week, triage failures over the next two, and flip the job to blocking once your dependencies are green. When 8.6.0 ships on the 19th of November, your CI is already running it, and the upgrade becomes a one-line change to your production image.

If your app is a PHP Architect style monolith with a long dependency tree, expect most friction in older packages that cap their PHP constraint. Those are the ones worth reporting early.

Sources