Skip to content

Switch to prophecy-phpunit trait#337

Closed
temp wants to merge 1 commit into
php-coveralls:masterfrom
temp:feature/prophecy-phpunit
Closed

Switch to prophecy-phpunit trait#337
temp wants to merge 1 commit into
php-coveralls:masterfrom
temp:feature/prophecy-phpunit

Conversation

@temp

@temp temp commented Dec 21, 2021

Copy link
Copy Markdown

Since prophecy-support in phpunit is deprecated, and will be remove in phpunit 10, this PR add prophecy-support via phpspec/prophecy-phpunit.

@temp

temp commented Dec 21, 2021

Copy link
Copy Markdown
Author

Oh sorry, didn't check for lower deps. Maybe it's time to let php < 7.3 go?

@keradus

keradus commented Dec 22, 2021

Copy link
Copy Markdown
Member

we recently got reports from users using this package for lower PHP when we accidentally broke it, I wouldn't go that path.
I would be OK to drop 5.x and 7.0 (as separated PR) base on these stats: https://packagist.org/packages/php-coveralls/php-coveralls/php-stats , but 7.1 should remain supported

@temp

temp commented Dec 22, 2021

Copy link
Copy Markdown
Author

Why? Raising minimum version isn't a breaking change, users with php < 7.3 can still use the old version.

@jrfnl

jrfnl commented May 24, 2022

Copy link
Copy Markdown
Contributor

FYI: there is a PR open in phpspec/prophecy-phpunit to widen the version restrictions - your support may help get it merged: phpspec/prophecy-phpunit#38

@keradus

keradus commented Sep 12, 2022

Copy link
Copy Markdown
Member

I believe we can drop <7.2 by now

@jrfnl

jrfnl commented Sep 12, 2022

Copy link
Copy Markdown
Contributor

I believe we can drop <7.2 by now

I have no objection to this change.

While this will make things slightly more difficult for projects which do code coverage runs on their high-low supported PHP versions if their "low" PHP version is below PHP 7.2, it can still work perfectly well as the PHP version on which the tests are run does not have to be the same PHP version on which code coverage is uploaded.

To do so, one would have to switch the PHP version within the CI job. With GH Actions and the shivammathur/setup-php action runner, this is not hard to do, it just requires adding an extra step.

I'm already doing this for a project which still supports PHP 5.4 (while the 2.x version of this package has a PHP 5.5 minimum).

Example code:

jobs:
  coverage:
      # ... All the normal config and steps to set up the environment and run the tests ...

      - name: Run the unit tests with code coverage
        run: vendor/bin/phpunit

      # Uploading the results with PHP Coveralls v2.x needs PHP 5.5+, so switch the PHP version.
      - name: Switch to PHP 7.4
        if: ${{ success() && matrix.php != '7.4' }}
        uses: shivammathur/setup-php@v2
        with:
          php-version: 7.4
          coverage: none

      - name: Install Coveralls
        if: ${{ success() }}
        run: composer require php-coveralls/php-coveralls:"^2.5.3"

      - name: Upload coverage results to Coveralls
        if: ${{ success() }}
        env:
          COVERALLS_REPO_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          COVERALLS_PARALLEL: true
          COVERALLS_FLAG_NAME: php-${{ matrix.php }}-phpcs-${{ matrix.phpcs_version }}
        run: vendor/bin/php-coveralls -v -x build/logs/clover.xml

Might be good to make people aware of this option to switch PHP versions within a job by documenting it in the README.

@keradus

keradus commented Sep 14, 2022

Copy link
Copy Markdown
Member

While this will make things slightly more difficult for projects which do code coverage runs on their high-low supported PHP versions if their "low" PHP version is below PHP 7.2, it can still work perfectly well as the PHP version on which the tests are run does not have to be the same PHP version on which code coverage is uploaded.

also, one could upload the coverage with php-coveralls v2.5.3. they will not receive any new versions of php-coveralls, but also not that much is changing in this project and they don't need to run cutting-edge version of php-coveralls, and running legacy PHP version could be bigger problem to start with ;)

@keradus

keradus commented May 12, 2025

Copy link
Copy Markdown
Member

replaced by #386

@keradus keradus closed this May 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants