framework #61819: [13.x] Database test improvements

Pull request #61819 is a chore-level, infrastructure-only change to laravel/framework's continuous integration setup — no files under src/Illuminate are touched, and nothing in your application's runtime path changes. It is a follow-up to #60005 (split out to avoid merge conflicts) and does four things: it sorts every database test job in ascending version order for readability, pins the MariaDB "floating 10" job to an explicit 10.11 image, adds integration test coverage for SQL Server 2022 and SQL Server 2025, and bumps most workflow runners from ubuntu-24.04 (and one lingering ubuntu-latest) to ubuntu-26.04.

What Changed

The databases.yml workflow now lists its jobs in a clean, ascending order, which makes the coverage matrix easy to scan on any pull request:

• MySQL: 5.7 → 8.4 → 9.7 (innovation release runs nightly)
• MariaDB: 10.11 → 11.8 → 12.3
• PostgreSQL: 10 → 14 → 18
• SQL Server: 2017 → 2019 → 2022 (new) → 2025 (new)
• SQLite: single job

Two jobs were materially reworked. The previously floating mariadb:10 image is now pinned to mariadb:10.11, and the job was renamed from mariadb to mariadb_10 with the display name "MariaDB 10.11". Two new jobs, mssql_2022 and mssql_2025, run tests/Integration/Database against Microsoft's 2022-latest and 2025-latest container images.

Almost every other workflow — tests.yml, databases-nightly.yml, redis.yml, queues.yml, static-analysis.yml, facades.yml, releases.yml, install-nightly.yml, update-assets.yml, and the per-component close-pull-request.yml files — moved to the ubuntu-26.04 runner image. Two deliberate exceptions exist: all SQL Server jobs stay on ubuntu-22.04 because the SQL Server containers err on newer runners, and the beanstalkd queue job stays on ubuntu-24.04 because beanstalkd's build fails on 26.04.

Why It Matters

CI coverage is your insurance policy. Pinning MariaDB to 10.11 removes ambiguity: the framework's documentation supports MariaDB 10.3+, but a floating mariadb:10 tag can silently drift as new 10.x images are published. Explicitly testing 10.11 — the oldest MariaDB v10 line that still receives maintained open-source images — means the version CI actually validates matches a known quantity.

The new SQL Server jobs close a real gap. SQL Server 2022 is a mainstream long-term release and SQL Server 2025 is the newest version Microsoft ships, yet framework's sqlsrv grammar was previously only exercised against 2017 and 2019. Any regression in query generation, upserts, or type handling specific to newer engines would now surface in CI before it reaches a production deploy.

Ascending job ordering is cosmetic on the surface but practical in effect: when a PR check list reads 2017, 2019, 2022, 2025, spotting a missing or failing version takes a glance instead of a hunt.

A Look at the New Coverage

The added SQL Server 2025 job looks like this (trimmed for clarity):

mssql_2025:
  # Errs on Ubuntu 26.04 (likely 24.04 as well)
  runs-on: ubuntu-22.04
  timeout-minutes: 10

  services:
    sqlsrv:
      image: mcr.microsoft.com/mssql/server:2025-latest
      env:
        ACCEPT_EULA: Y
        SA_PASSWORD: Forge123
      ports:
        - 1433:1433

  name: SQL Server 2025

  steps:
    - name: Execute tests
      run: vendor/bin/phpunit tests/Integration/Database
      env:
        DB_CONNECTION: sqlsrv
        DB_DATABASE: master
        DB_USERNAME: SA
        DB_PASSWORD: Forge123

Because the CI configuration mirrors what real deployments need, you can reproduce this exact scenario locally to smoke-test your own application against the newest engine:

docker run -d -e "ACCEPT_EULA=Y" -e "SA_PASSWORD=Forge123" -p 1433:1433 \
  mcr.microsoft.com/mssql/server:2025-latest

DB_CONNECTION=sqlsrv DB_DATABASE=master DB_USERNAME=SA DB_PASSWORD=Forge123 \
  vendor/bin/phpunit tests/Integration/Database

Upgrade Impact

Coming from v13.34.0, there is nothing to do. No API surface, configuration, service provider, or dependency changes ship with this pull request — the composer.json and framework source are untouched, so upgrading is behaviorally inert for applications.

Two audiences should still take note:

• Contributors: the checks list on your pull requests will look different — jobs appear in ascending version order, mariadb is now mariadb_10, and two additional SQL Server checks will run. That's expected, not breakage.
• Fork maintainers: if you mirror laravel's workflow files in your own infrastructure, sync the changes deliberately. Remember that SQL Server jobs must remain pinned to ubuntu-22.04 and beanstalkd to ubuntu-24.04; copying the blanket 26.04 bump without those exceptions will break those jobs.

Takeaways

• Zero runtime impact — this PR touches only GitHub Actions workflows; no source, config, or dependency changes, so no action is needed when upgrading from v13.34.0.
• MariaDB is now pinned to 10.11 instead of a floating mariadb:10 image, making the lowest tested version explicit.
• SQL Server 2022 and 2025 are newly covered by the integration test suite, extending database grammar verification to Microsoft's current releases.
• All database test jobs are sorted ascending by version, making the CI matrix easier to audit at a glance.
• Runners moved to ubuntu-26.04 across most workflows, with intentional exceptions: SQL Server jobs stay on 22.04 and beanstalkd stays on 24.04.
• If you maintain a fork with copied workflow files, pull these changes in and keep the two runner exceptions intact.

Sources

• Pull request #61819
• Release v13.35.0