Switch back to ext-mongodb latest stable after the release of 2.5.0 - #1979
Conversation
There was a problem hiding this comment.
🟢 Approval recommended
The change is a straightforward workflow configuration revert and the "stable" value is consistently passed through the existing setup action as intended.
Pull request overview
This PR updates the GitHub Actions CI workflows to use the latest stable ext-mongodb release again (instead of tracking the v2.x branch), aligning CI with the post-2.5.0 release state referenced in the PR description.
Changes:
- Switch
DRIVER_VERSIONfrommongodb/mongo-php-driver@v2.xback to"stable"in CI workflows. - Remove the temporary TODO comments that were guarding the pre-2.5.0 configuration.
File summaries
| File | Description |
|---|---|
| .github/workflows/tests.yml | Uses DRIVER_VERSION: "stable" for the PHPUnit matrix runs. |
| .github/workflows/static-analysis.yml | Uses DRIVER_VERSION: "stable" for Psalm/static analysis runs. |
| .github/workflows/generator.yml | Uses DRIVER_VERSION: "stable" for generator diff checks. |
| .github/workflows/coding-standards.yml | Uses DRIVER_VERSION: "stable" for PHPCS and Rector jobs. |
Review details
- Files reviewed: 4/4 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
There was a problem hiding this comment.
🟢 Approval recommended
The changes are limited to CI configuration and consistently switch extension installation back to stable while keeping the “lowest” job aligned with the declared ext-mongodb ^2.5 requirement.
Review details
- Files reviewed: 5/6 changed files
- Comments generated: 0 new
- Review effort level: Lite
There was a problem hiding this comment.
🟡 Changes recommended
The GitHub Actions matrix expression uses an invalid property access for a hyphenated key (matrix.driver-lowest), which will break selecting the intended lowest driver version.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Review details
- Files reviewed: 5/6 changed files
- Comments generated: 1
- Review effort level: Lite
Evergreen build tasks now select a symbolic EXTENSION_TARGET, resolved by compile-extension.sh, so no extension version number is left in the CI configuration. GitHub Actions gets a dedicated job for the lowest supported extension version. Switching to an unreleased extension is now a single variable per CI system, and a new check fails if it is left enabled.
There was a problem hiding this comment.
🟡 Changes recommended
The updated CI logic contains concrete issues that can lead to incorrect extension-version resolution/caching and an Evergreen config diff check that may miss newly generated untracked files.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Review details
Suppressed comments (1)
.github/actions/setup/action.yml:63
- The cache key always hashes the repository-root composer.json. If
working-directorypoints to a different composer.json, the cache may be reused across different dependency/constraint sets, which can lead to installing the wrong cached extension build.
key: "extcache-${{ steps.driver.outputs.version }}-${{ hashFiles('composer.json') }}"
- Files reviewed: 9/10 changed files
- Comments generated: 3
- Review effort level: Lite
The release workflow now fails before creating the tag if the extension dev branch is still enabled. This check replaces the one added to the generator workflow, which was based on the pull request base branch. RELEASING.md no longer asks to bump the extension requirement, as composer.json is updated during development.
There was a problem hiding this comment.
🟡 Changes recommended
The GitHub Actions setup composite action currently constructs invalid extension identifiers (e.g. mongodb-stable / double-prefixing), which is likely to break CI until fixed.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Review details
Suppressed comments (3)
.github/actions/setup/action.yml:64
cache-extensionsis currently givenmongodb-${{ steps.driver.outputs.version }}; after resolution this can already be a full extension spec (e.g.mongodb-2.5.0ormongodb). Prefixing again produces invalid values likemongodb-mongodb-2.5.0.
php-version: ${{ inputs.php-version }}
extensions: "mongodb-${{ steps.driver.outputs.version }}"
key: "extcache-${{ steps.driver.outputs.version }}-${{ hashFiles('composer.json') }}"
.github/actions/setup/action.yml:96
- The version-check step compares against
steps.driver.outputs.version, which is not necessarily a semver (and is explicitly overridden when building from a dev branch). If you emit anexpectedoutput only for thelowestcase, you can both guard the step and compare against the semver value reliably.
- name: Check the expected driver version is installed
if: inputs.driver-version == 'lowest'
shell: bash
run: |
INSTALLED=$(php -r 'echo phpversion("mongodb");')
EXPECTED="${{ steps.driver.outputs.version }}"
if [ "$INSTALLED" != "$EXPECTED" ]; then
echo "::error::Expected extension version $EXPECTED, got $INSTALLED"
exit 1
.github/actions/setup/action.yml:79
setup-phpis currently invoked withextensions: "mongodb-${{ steps.driver.outputs.version }}", which becomes invalid for the resolved values (e.g.mongodb-stable,mongodb-mongodb-2.5.0, ormongodb-mongodb/mongo-php-driver@v2.x). It should receive the fully resolved extension spec directly.
uses: shivammathur/setup-php@v2
with:
coverage: xdebug
extensions: "mongodb-${{ steps.driver.outputs.version }}"
php-version: "${{ inputs.php-version }}"
- Files reviewed: 10/11 changed files
- Comments generated: 1
- Review effort level: Lite
Read composer.json from the working directory when the input is set, validate the constraint format before parsing it, and detect new generated files in the Evergreen config diff check.
There was a problem hiding this comment.
🟡 Changes recommended
The new GitHub Actions setup logic has a couple of correctness/operational edge cases (cache key derivation and the lowest version verification interacting with dev-branch mode) that should be addressed before merging.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Review details
Suppressed comments (1)
Previously missed (1) — in code that hasn't changed since the last review.
.github/actions/setup/action.yml:10
- The
driver-versioninput description says "stable" installs the highest version allowed by composer.json, but the action does not consult composer.json for the stable path (it passes the string through to setup-php). This description can mislead readers into thinking the constraint is enforced here rather than by Composer later.
- Files reviewed: 10/11 changed files
- Comments generated: 2
- Review effort level: Lite
.extension-version is sourced by the Evergreen build script and by the GitHub setup action. It holds the extension branches and the EXTENSION_REQUIRE_NEXT_MINOR flag, so depending on an unreleased extension is a single line to change for both CI systems. The release workflow fails while the flag is enabled.
There was a problem hiding this comment.
🔵 Needs a closer look
The GitHub Actions setup action currently caches the stable extension target, which can freeze CI on an older cached release and undermine the intent to test against the latest stable PECL version.
Review details
Suppressed comments (1)
Previously missed (1) — in code that hasn't changed since the last review.
.github/actions/setup/action.yml:66
stableis treated as cacheable, but it is a moving target (new PECL releases). Caching under a stable key can cause CI to keep using an older cached extension version and not actually test against the latest stable release as intended. Consider disabling caching for thestabletarget (or alternatively, key the cache by the resolved concrete version).
- Files reviewed: 11/12 changed files
- Comments generated: 0 new
- Review effort level: Lite
The stable target used to install whatever PECL serves, ignoring the ext-mongodb constraint, and no concrete version was part of the GitHub Actions cache key. Both CI systems now resolve the highest release allowed by the constraint, and the cache key goes back to a plain invalidation marker, the requested version being already part of the key computed by cache-extensions.
There was a problem hiding this comment.
🟡 Changes recommended
The new CI helper script should validate arguments/targets explicitly to avoid silent misconfiguration and unclear failures in automation.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Review details
- Files reviewed: 12/13 changed files
- Comments generated: 2
- Review effort level: Lite
The ext-mongodb constraint in composer.json and the versions published on PECL are now the only inputs. tools/extension-version.php resolves the target for both CI systems, so the .extension-version file and its three hand maintained variables are gone, as is the Python resolver. A constraint that no published version satisfies makes every job build the extension from its development branch, which replaces the manual switch. The release workflow checks that a published version matches the constraint. The resolution now always reads the composer.json of the repository root, which fixes the generator job, as generator/composer.json does not declare the extension.
There was a problem hiding this comment.
🟡 Changes recommended
The resolver output is currently unsafe to eval without escaping, and the composite setup action’s resolution still ignores working-directory, which can install the wrong extension version in non-root usages.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Review details
- Files reviewed: 11/12 changed files
- Comments generated: 4
- Review effort level: Lite
Only version numbers are matched in the PECL document, so the output stays safe to evaluate in a shell. An unreadable or invalid composer.json now fails with an explicit message, and the expansions passed to the resolver are quoted.
There was a problem hiding this comment.
🟡 Changes recommended
The GitHub Actions composite setup action emits an invalid setup-php extension spec for source builds (missing the required mongodb- prefix), which can break CI exactly when the constraint is not yet released.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Review details
- Files reviewed: 11/12 changed files
- Comments generated: 2
- Review effort level: Lite
There was a problem hiding this comment.
🟢 Approval recommended
The changes consistently centralize extension version selection across CI systems, align documentation and workflows, and the updated scripts/configs appear coherent with the repository’s current ext-mongodb constraint.
Review details
- Files reviewed: 11/12 changed files
- Comments generated: 0 new
- Review effort level: Lite
CI selects the version of the extension to test from the
ext-mongodbconstraint incomposer.jsonand the versions published on PECL. There is nothing else to maintain: no configuration file, no flag to toggle, no branch name to keep in sync.Changing the required extension version
Bump
ext-mongodbincomposer.json, and you are done. Both Evergreen and GitHub Actions follow.If you bump it to a version that is not released yet, no published version satisfies the constraint, so every job compiles the extension from its development branch. The lowest supported version is not tested while this lasts, as the library code cannot run on it. Once the extension is released, both CI systems go back to released versions on their own, with nothing to revert. The release workflow refuses to create a tag until a published version matches the constraint.
What CI tests
php tools/extension-version.php stableresolves any of these targets locally, the same way CI does. The "Continuous integration" section of CONTRIBUTING.md documents it.