Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Building the CI Build Matrix #6620

Open
morozov opened this issue Nov 20, 2024 · 0 comments
Open

Building the CI Build Matrix #6620

morozov opened this issue Nov 20, 2024 · 0 comments

Comments

@morozov
Copy link
Member

morozov commented Nov 20, 2024

The goal is to provide high test coverage of the library code together with various supported dependencies while keeping the number of test jobs to the necessary minimum.

Types of Dependencies

  1. PHP versions: Every supported minor version and nightly.
  2. Database platforms and their versions (platform-specific, see below).
  3. Composer packages: Lowest and highest versions.

Database Platform Versions to be Tested

  1. The lowest and highest supported versions.
  2. Intermediate versions for which there is a dedicated code path in the library.
  3. LTS releases are preferred over non-LTS ones, even if the dedicated code path would be triggered by an older non-LTS version.

Proposed Pattern

  1. Latest stable PHP version: Test all combinations with each supported driver and all respective database platform versions matching the above requirements.
  2. Other supported PHP versions: Test with each supported driver and the latest version of the respective database platform.
  3. SQLite drivers: Test with the lowest supported and latest stable PHP versions.
  4. Composer dependencies:
    • Use the lowest Composer dependencies with the lowest supported PHP version and pdo_sqlite (our historical default driver).
    • Use the highest Composer dependencies in all other builds.

Code Coverage

Code coverage can serve as an indicator of over- or under-testing. If the removal of a job that uses some intermediate dependency version(s) does not result in a drop in code coverage, it means that no dedicated code path exists for this configuration. In such a case, it is a strong signal of that testing this configuration is unnecessary, and thus, we don't want to spend machine time testing it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant