This commit changes Travis configuration to only install Chrome and Nginx in the e2e tests build job, which is the only one that requires those packages. This change should save a little bit of time in the Travis build as before Travis was installing Chrome and Nginx in all the jobs.
PR https://github.com/woocommerce/woocommerce/pull/23082 made some changes to the Travis configuration and one of those changes broke the PHPCS when running inside Travis with the following error:
```
ERROR: Referenced sniff "WooCommerce-Core" does not exist
```
For example: https://travis-ci.org/woocommerce/woocommerce/jobs/509471213#L659
This problem went unnoticed during the PR review as no PHP file was modified in it and thus there was no file for PHPCS to check.
This commit fixes the error above by installing the Composer package `woocommerce/woocommerce-sniffs` which is the package that provides `WooCommerce-Core` sniffs and which installs `wp-coding-standards/wpcs` as one of its requirements. I couldn't find an easy way to make this work installing `woocommerce/woocommerce-sniffs` globally so that is why this commit also removes the `global` parameter when calling composer.
This commit creates two new Travis build jobs, one to run the e2e tests and another to run PHPCS. Doing this, instead of running those two checks in the same build job as the PHP 7.2 unit tests, should make the total build time shorter and it should make it easier to see why the build failed.
Due to a recent change in the Travis environment, WooCommerce unit tests stopped working with the following error (see for example https://travis-ci.org/woocommerce/woocommerce/jobs/463470674#L876) in the PHP 7.2 and 7.3 build jobs:
Fatal error: Class PHPUnit_Util_Test may not inherit from final class (PHPUnit\Util\Test) in /tmp/wordpress-tests-lib/includes/phpunit6-compat.php on line 18
This error is happening because Travis started ignoring the PHPUnit version that we install manually via Composer (f7bc3fb851/tests/bin/travis.sh (L6)) and started using the PHPUnit version that is shipped with each of its PHP docker images. This means that for the docker images running PHP 7.2 and 7.3, PHPUnit 7 is used but the WordPress unit test framework is not compatible with PHPUnit 7 (see WordPress core ticket https://core.trac.wordpress.org/ticket/43218) and produces the error above. I believe that this is happening because Travis changed the directory where it installs composer global packages from `$HOME/.composer/` to `$HOME/.config/composer/` (https://github.com/travis-ci/travis-ci/issues/7289#issuecomment-427333966) and we add `$HOME/.composer/vendor/bin:$PATH` to the `$PATH`. So this commit simply updates the path in the line where we add it to the `$PATH`.
I tried to use `composer exec` instead of updating `$PATH` but that didn't work for PHP 5.2.
Now that all the required changes to make WooCommerce work fine with PHP 7.3 were implemented, it is safe to remove PHP 7.3 from the list of Travis build jobs that are allowed to fail.
To make it easier to test WC running the upcoming PHP 7.3, this commit changes the PHP 7.3 Travis build to run unit tests using WP 5.0-beta5. This way we won't display WP core warnings related to PHP 7.3 that were already fixed in the upcoming WP version and will be able to see only WC related warnings.
My initial plan was to use WP nightly but that didn't work as nightly is still build from trunk and WP 5.0 development is being done on another branch (https://make.wordpress.org/core/2018/10/05/wordpress-5-0-commit-management/).
This commit adds an if to check if xdebug.ini exists before trying to remove it. Doing this to avoid a build error in PHP versions where the file doesn't exist like PHP 7.3.
Tests should be consistent. That is true for our unit tests suite, but it is something that is harded to achieve for functional tests. Our end to end tests often times fail due to factors outside of our control, and simply manually restarting the Travis build is enough to make them pass (example: https://github.com/woocommerce/woocommerce/pull/21150#issuecomment-415132390). This commits uses `travis_retry` to make Travis automatically retry a maximum of three times to run WC e2e tests in case of a failure.
This commit changes the travis codecoverage from using xdebug to phpdbg, phpdbg seems much faster and gives similar results.
Reason for switching is we have been running into constant timeouts on our codecoverage due to the 50min job limit on travis, which means our codecoverage has not been updated in a couple of months.
* Remove xdebug as it slows tests down, switch to using phpdbg for code coverage.
* Update parameters for phpdbg
* It is qrr not qqr
* Include vendor/bin path when using phpdbg
* Use PHP 7.1 to run phpdbg
* Update phpunit dire
* Include $HOME in phpdbg call to phpunit
* Set no memory limit to avoid out of memory errors.
* Assign timeout group to test_request_url test for paypal and do not execute that on coverage as it causes a memeory timeout. Test needs optimization to run for code coverage.
* @covers usage for methods should be prefixed with ::
PR #17680 added a new PHP 7.1 Travis build job to generate code coverage report. PHPCS was configured to run on all PHP 7.1 build jobs. So this means that after #17680 was merged, Travis started running PHPCS twice.
This commit fixes this issue by setting a new environment variable called `$RUN_PHPCS` and using this variable, instead of the PHP version, to decide when to run PHPCS.
This commit changes Travis configuration file to specify a list of branches that it should build. This way Travis will only create a new build when a commit is pushed to the master branch and release branches and when tags are created. The behavior for PRs is not modified and PR creation and updates will still trigger builds.
Doing this to speed up Travis build by preventing it from running two builds for PR that are created from a branch of the same repository. Before this change, Travis would create a build when the branch is pushed to GitHub (continuous-integration/travis-ci/push) and another one when the PR is created (continuous-integration/travis-ci/pr). For an example, see https://github.com/woocommerce/woocommerce/pull/17680.
It is not necessary to declare environment variables for a specific build job if they are the same as the environment variables declared for all build jobs.
Gerhard
Claudio Sanches
Peter Fabian
Mike Jolley
Rodrigo Primo
Brent Sessions