-
Notifications
You must be signed in to change notification settings - Fork 498
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
CI: switch to GitHub Actions for PHP 5.5 - current #467
Conversation
b603d08
to
a1d1d63
Compare
Note: these workflows will automatically be disregarded for the |
FYI: The linting failure against PHP 8.1 as can currently be seen, is unrelated to this repo. I've opened an issue about this with the |
FYI: The issue in the |
This commit: * Adds a GH Actions workflow for the CI checks which were previously run on Travis in the `sniff` stage. * Removes that part of the `.travis.yml` configuration. * Adds a "Build Status" badge in the Readme to use the results from this particular GH Actions runs. Co-authored-by: Alain Schlesser <[email protected]>
This commit: * Add a new dependency on the PHP Parallel Lint package which will be used for linting on PHP >= 5.5. The PHP Parallel Lint package, in combination with the PHP Console Highlighter provides the following advantages in comparison with "plain" PHP linting: - Higher speed due to the parallel processes. - Improved usability by providing color coded syntax highlighting of found errors on the command-line. - Integration with the `cs2pr` tool, allowing for the results of the lint command to be shown in-line in PRs. * Adds a Composer `lint` script for easy access to the tool for devs, while making sure the correct command line parameters will be used. * Adds a GH Actions workflow for linting the code on the high/low minors of each PHP major version. Note: this workflow will only run on PHP >= 5.5. Linting against PHP 5.2 - 5.4 will remain in Travis for now. * Removes the part of the `.travis.yml` configuration which has now been replaced. * Adds a "Build Status" badge in the Readme to use the results from this particular GH Actions runs. Co-authored-by: Alain Schlesser <[email protected]>
a1d1d63
to
dbcbd64
Compare
dbcbd64
to
96c9e2f
Compare
Fixed up in the existing commits and force pushed (only changes those mentioned above). |
This commit: * Adds a GH Actions workflow for running the unit tests against PHP 5.5 - current. Note: - This workflow will run for all pull requests and for merges to master, but not for other push events. - Code coverage will be checked for the highest and lowest PHP version so the results can be combined to cover any polyfills and work-arounds. Includes adjusting the codecov configuration to expect 2 reports for each build. - The PHP 8.1 (nightly) job is "allowed to fail" (`experimental` = true). If it does fail, the build status will unfortunately show as "failed", even though all non-experimental jobs have succeeded. This is a known issue in GHA: https://github.com/actions/toolkit/issues/399 - For PHP 5.2-5.4, the tests will still be run via Travis as the test server setup is incompatible with PHP < 5.5 and using multiple PHP versions in a workflow run does work on Travis, but doesn't work the same on GH Actions. * Strips down the `.travis.yml` configuration to the bare minimum to run the tests against PHP 5.2 - 5.4. * Adds a "Build Status" badge in the Readme to use the results from this particular GH Actions runs. Note: for the time being, the tests will not be run against PHP 8.1/nightly as PHPUnit 7 is incompatible, meaning that that build would _always_ fail. Once the version constraints for PHHUnit have been widened (see PR 446), the build against PHP nightly should be enabled. Co-authored-by: Alain Schlesser <[email protected]>
Previous, the Travis all-in-one workflow would run on every push and every PR, making for a lot of redundancy in the builds. GH Actions allows to run workflows far more selectively. The "Test" workflow has been configured to run against all supported PHP versions for pushes (merges) to `master`, as well as for pull requests. This commit introduces a "Quick test" workflow, which is basically the same as the full "Test" workflow (without code coverage checking). This workflow will only run the tests against a few select PHP versions on `push` events, when the push is not to the `master` branch. This allows for people working on feature branches to still get a quick impression of whether their branch is ready to be pulled, while conserving resources by not running the full build until the branch has been pulled. Co-authored-by: Alain Schlesser <[email protected]>
96c9e2f
to
44895bf
Compare
Depends on: PRs actions/toolkit#458 (and by extension PR actions/toolkit#457) and actions/toolkit#464.
Those PRs will need to be merged before this PR can become mergable.
Supersedes: PRs actions/toolkit#447 and actions/toolkit#461
Closes actions/toolkit#447
Closes actions/toolkit#461
TL;DR
This PR moves the CI checks for PHP 5.5 - current to GH Actions, while leaving the CI checks against PHP 5.2 - 5.4 to be run via Travis. This allows for this move to be done now while PHP 5.2 - 5.4 are still supported and will still safeguard (via Travis) that the code is still compatible with PHP 5.2 - 5.4.
This PR incorporates the work previously done by @schlessera in actions/toolkit#447 and builds on that.
Background of why the PHP 5.2-5.4 builds won't be able to move to GH Actions:
The code of the test-server used during the running of the unit tests requires PHP 5.5 minimum due to the use of
yield
.On Travis, it is possible to use PHP 5.6 to start and run the test server, while running the tests themselves on a lower PHP version within the same workflow.
On GH Actions, while it is possible to switch PHP versions during a workflow, this switch will affect all code, so the test server can not run on a different PHP version than the tests, effectively blocking PHP 5.2-5.4.
Commit details
CI: switch to GitHub Actions - step 1: sniff/CS workflow
This commit:
sniff
stage..travis.yml
configuration.CI: switch to GitHub Actions - step 2: lint workflow
This commit:
The PHP Parallel Lint package, in combination with the PHP Console Highlighter provides the following advantages in comparison with "plain" PHP linting:
cs2pr
tool, allowing for the results of the lint command to be shown in-line in PRs.lint
script for easy access to the tool for devs, while making sure the correct command line parameters will be used.Note: this workflow will only run on PHP >= 5.4. Linting against PHP 5.2 and 5.3 will remain in Travis for now.
.travis.yml
configuration which has now been replaced.Fix proxy scripts to work with newest mitmproxy release
Add edge case TODO for fsockopen invalid auth test
CI: switch to GitHub Actions - step 3: test and coverage stage
This commit:
Note:
Includes adjusting the codecov configuration to expect 2 reports for each build.
experimental
= true). If it does fail, the build status will unfortunately show as "failed", even though all non-experimental jobs have succeeded.This is a known issue in GHA: Please support something like "allow-failure" for a given job actions/runner#2347
.travis.yml
configuration to the bare minimum to run the tests against PHP 5.2 - 5.4.Note: for the time being, the tests will not be run against PHP 8.1/nightly as PHPUnit 7 is incompatible, meaning that that build would always fail.
Once the version constraints for PHPUnit have been widened (see PR actions/toolkit#446), the build against PHP nightly should be enabled.
CI: switch to GitHub Actions - step 4: introduce a quick test workflow
Previous, the Travis all-in-one workflow would run on every push and every PR, making for a lot of redundancy in the builds.
GH Actions allows to run workflows far more selectively.
The "Test" workflow has been configured to run against all supported PHP versions for pushes (merges) to
master
, as well as for pull requests.This commit introduces a "Quick test" workflow, which is basically the same as the full "Test" workflow (without code coverage checking).
This workflow will only run the tests against a few select PHP versions on
push
events, when the push is not to themaster
branch.This allows for people working on feature branches to still get a quick impression of whether their branch is ready to be pulled, while conserving resources by not running the full build until the branch has been pulled.