GH Actions/verify release: tweak the workflow #1092
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As of PHPCS 4.0.0, a new "No files were checked" error will be shown if `phpcs`/`phpcbf` runs a scan and no files end up being scanned.
Previously, to test that the downloaded PHAR file is nominally functional, the `php ${{ steps.source.outputs.FILE }} . -e --standard=PSR12` command was used.
For `phpcs`, this would "explain" the PSR12 standard, for `phpcbf`, this would spin up PHPCS and end up not scanning anything as there are no files in the working directory, but it did test that the PHAR file was functional.
This "trick" will no longer work with PHPCS 4.0.0 due to the new "No files were checked" error.
As I'd prefer for this check to do a simple scan, rather than exit out while reading the CLI arguments (like would happen with the `-h` or `-i` flags), I'm now implementing the suggestion made by fredden in https://github.com/PHPCSStandards/PHP_CodeSniffer/pull/758/files#diff-c871a3c5382d363c3ead11f0f87306fd5954b360eaa8a96fea8582bce1815827 and creating a simple PHP file to scan.
PHIVE does not support a "stability" flag yet, which means that it will always grab the very latest release, even when this is an alpha/beta/RC pre-release. As the GH API `releases/latest` route returns the latest _stable_ release, this causes the workflow to fail. This was already previously identified as an area which needed attention in #758, and as we now have a pre-release as the latest release (`4.0.0beta1`), this now needs to be fixed. Note: this still doesn't fix things completely, as in reality, the workflow should work based on the tag published if the workflow is triggered by a release to ensure that the "release assets" and "versioned web" jobs check the right release ("unversioned web" should still always check the latest stable release), but it is unclear where to grab that info from and as testing the info available when the workflow is triggered by a release requires doing a release, this is neigh impossible to test. I may need to create a dummy repo just to test. For now, this at least fixes the Phive jobs.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
GH Actions/verify release: tweak the workflow [1]
As of PHPCS 4.0.0, a new "No files were checked" error will be shown if
phpcs/phpcbfruns a scan and no files end up being scanned.Previously, to test that the downloaded PHAR file is nominally functional, the
php ${{ steps.source.outputs.FILE }} . -e --standard=PSR12command was used.For
phpcs, this would "explain" the PSR12 standard, forphpcbf, this would spin up PHPCS and end up not scanning anything as there are no files in the working directory, but it did test that the PHAR file was functional.This "trick" will no longer work with PHPCS 4.0.0 due to the new "No files were checked" error.
As I'd prefer for this check to do a simple scan, rather than exit out while reading the CLI arguments (like would happen with the
-hor-iflags), I'm now implementing the suggestion made by @fredden in https://github.com/PHPCSStandards/PHP_CodeSniffer/pull/758/files#diff-c871a3c5382d363c3ead11f0f87306fd5954b360eaa8a96fea8582bce1815827 and creating a simple PHP file to scan.GH Actions/verify release: tweak the workflow [2]
PHIVE does not support a "stability" flag yet, which means that it will always grab the very latest release, even when this is an alpha/beta/RC pre-release.
As the GH API
releases/latestroute returns the latest stable release, this causes the workflow to fail.This was already previously identified as an area which needed attention in #758, and as we now have a pre-release as the latest release (
4.0.0beta1), this now needs to be fixed.Note: this still doesn't fix things completely, as in reality, the workflow should work based on the tag published if the workflow is triggered by a release to ensure that the "release assets" and "versioned web" jobs check the right release ("unversioned web" should still always check the latest stable release), but it is unclear where to grab that info from and as testing the info available when the workflow is triggered by a release requires doing a release, this is neigh impossible to test. I may need to create a dummy repo just to test.
For now, this at least fixes the Phive jobs.
Suggested changelog entry
N/A