GH Actions: improve workflows #55

To disable code coverage, the `coverage` key should be set to `none`. `false` is not a valid (or supported) value, so the behaviour may be unpredictable. Ref: https://github.com/shivammathur/setup-php#disable-coverage

The original Travis script ran the following commands against *all* supported PHP versions, but didn't test the phar: ```yaml - composer test - ./parallel-lint --exclude vendor --exclude tests/examples --no-colors . - ./parallel-lint --exclude vendor --exclude tests/examples . ``` The current `test` job only ran the unit tests against PHP 5.4. It did not run the integration test (running Parallel Lint against its own code) via a direct call to the script anymore at all. The integration test was basically now _only_ being run for the phar and only in one flavour, though it did do that on all supported PHP versions. This commit: * Removes the job which only ran the unit tests against PHP 5.4. * Adds the running of the above three commands (unit tests and two versions of integrations tests runs via a direct call to the script), to the job which also runs the integration tests via the phar file. * Updates the command line parameters used for the phar run to be the same as those used for the direct script call integration tests.

This fixes the problem originally identified by roelofr with the `Fatal error: Interface 'JsonSerializable' not found` error. The problem had nothing to do with the PHP setup, but everything with some inane setting of the Nette testing framework as can be seen in the transcript of older, failing trial runs done by roelofr while setting up the GH Actions workflows: ``` Run composer test > @php vendor/bin/tester -p php tests _____ ___ ___ _____ ___ ___ |_ _/ __)( __/_ _/ __)| _ ) |_| \___ /___) |_| \___ |_|_\ v2.3.5 Note: No php.ini is used. ``` The key here is the `Note: No php.ini is used.`. As the system `php.ini` was not being used, no extensions were loaded, which was causing the errors. This is a change which was introduced in Nette Tester 2.0.0. As of that version, you need to always tell the Nette testing framework explicitly which `php.ini` file to use, `-C` tells it to use the system-wide `php.ini`, with `-c` you can specify a path to a `php.ini` file and by default **_no `php.ini` is used_**. (_honestly, why did anyone ever think making that the default was a good idea ?!!?_) As the tests will be running on different versions of the Nette Framework, Nette 1.x for PHP 5.4 and 5.5 and Nette 2.x for PHP 5.6+ and Nette 1.x, does not yet support the `-C` option and breaks when it is used, I've added a second test script to the `composer.json` file with the correct command line options to run Nette on PHP 5.4/5.5 and added conditions to the GH Actions workflow to use the correct script depending on the PHP/Nette test framework version being used. Refs: * https://tester.nette.org/en/running-tests#toc-c-path * https://tester.nette.org/en/guide#toc-supported-php-versions * https://github.com/nette/tester/releases/tag/v2.0.0

Triggering a workflow for a branch manually is not supported by default in GH Actions, but has to be explicitly allowed. This is useful if, for instance, an external action script or composer dependency has broken. Once a fix is available, failing builds for open PRs can be retriggered manually instead of having to be re-pushed to retrigger the workflow. Ref: https://github.blog/changelog/2020-07-06-github-actions-manual-triggers-with-workflow_dispatch/

The cs2pr tool will allow to display the results from an action run in checkstyle format in-line in the PR code view, which should improve usability of the workflow results. This implements this for the style check command. Includes switching the PHP version to PHP 7.4, as PHP 8.0 is not fully supported yet in PHP_CodeSniffer (full support expected in PHPCS 3.6.0). Ref: https://github.com/staabm/annotate-pull-request-from-checkstyle

* Remove the now redundant Travis script. * Remove the reference to the Travis script from `.gitattributes` and add the new `.github` folder. * Update the "Build status" badge in the README to show the result of the GH Actions run instead of Travis. Supersedes 54 Co-authored-by: Sam Reed <sam@reedyboy.net>

In anticipation of PR 51 being merged, I'm already adding an extra step to the `test` job. PHP_CodeSniffer has a minimum PHP requirement of PHP 5.4, which would block the `composer install` on PHP 5.3. By removing that `dev` dependency ahead of the `composer install`, the test workflow can also run on PHP 5.3.

The `phar` file should only contain the files of PHP Parallel Lint and any non-dev requirements. It should not include the `dev` requirements of this package. As things were, it did. Fixed now, by doing the `composer install` with the `--no-dev` option, both for the Test workflow as well as for the Release workflow.

... and add `continue-on-error` to the first of the integration tests. If/when any of the tests fail, execution of the `Test` job will stop. Now, if there is a parse error in the code of any of the Parallel Lint files, with the test execution order as it was, that means the job would already fail on the running of the unit tests and stop there. However to identify the parse error, the integration tests are more useful, so with that in mind, those will now be run first. Secondly, if there is a parse error, the first integration test would fail and the second (with colours) would never get executed, while especially in the case of a parse error in the Parallel Lint code itself, it is useful to see the output of both these integration tests. So, with that in mind, I've set the first of the two to `continue-on-error`. As the second integration test would fail anyway, this will never negatively impact the workflow success/failure marking in the end, while it does allow us to see the output of both integration test steps.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

GH Actions: improve workflows #55

GH Actions: improve workflows #55

Commits on Mar 28, 2021