-
Notifications
You must be signed in to change notification settings - Fork 99
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
Move CI to GitHub Actions #814
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good stuff.
I requested one change – marked with
strategy: | ||
fail-fast: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
strategy: | |
fail-fast: true |
fail-fast
defaults to true
, so this isn't strictly necessary.
|
||
<!-- Include Alley Rules --> | ||
<rule ref="Alley-Interactive"> | ||
<!-- See #659. --> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not following based on the context provided in that issue. Why is long array syntax still allowed?
If one of the goals of this PR is to follow Alley coding standards, then this seems like a better time than any to enforce Generic.Arrays.DisallowLongArraySyntax
and automatically apply the required fixes with phpcbf
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just seemed out of scope. It probably would wipe out a lot of open PRs, too. But I'm not totally against it if folks think now is the time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Co-authored-by: Chris Montgomery <[email protected]>
Since there aren't any runtime dependencies that would need to be locked, and since we want CI runners to install the versions of dependencies appropriate to whatever version of PHP they're running, it's not clear what the Composer lockfile would be locked to.
This reverts commit 0a7f9d1.
After @montchr astutely pointed out my misunderstanding of how GitHub Actions work, I think the tests are now actually running on PHP 5.6 and 8.0, not just 7.4. This process brought in yet more changes for compatibility with newer versions of PHPUnit and with the forthcoming WordPress 5.9, which can be seen here: 07a23e4...2f7cf34 Most notably, Fieldmanager tests cases are now structured as extensions of the test case classes provided by the PHPUnit Polyfills library, rather than PHPUnit itself. The visible effect of this change is that Under the hood, PHPUnit 5 or 7 is installed by Composer for PHP 5.6 or PHP 7.4+, respectively. (PHPUnit 7 doesn't technically support PHP 8 but can be installed anyway using PHPUnit assertions used in the tests that are deprecated or removed in PHPUnit 7+ have been updated, such as migrating We should be in a position to adopt PHPUnit 9 once Fieldmanager's minimum supported version of WordPress is 5.9 or greater — WordPress 5.8 supports only PHPUnit 7. At that time, we'll also be able to remove PHPUnit from our |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🗡️
Left a few suggestions!
on: | ||
pull_request: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can also set up as such:
on: | |
pull_request: | |
on: pull_request |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comes from other Alley projects, and I'm inclined to keep it consistent with those so that it's easier to pick up the Fieldmanager config if you're used to other Alley defaults.
uses: shivammathur/setup-php@v2 | ||
with: | ||
php-version: '7.4' | ||
extensions: dom, curl, libxml, mbstring, zip, pcntl, pdo, sqlite, pdo_sqlite, gd |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we sure we need to add all those extensions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I'm not sure. Going with the flow of defaults used in other Alley projects here as well. I'm happy for someone who knows more about where those came from to make adjustments to this list, but I'm not personally comfortable trying to do that yet.
max_attempts: 5 | ||
command: composer install | ||
|
||
- name: Run PHPCS |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Recommend validating the composer package with:
- name: Validate Composer
run: composer validate --strict
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This happens in phpunit.yml
, although I suppose it makes more sense here so it runs once instead of on each of the PHPUnit variations.
access_token: ${{ github.token }} | ||
|
||
- name: Check out code | ||
uses: actions/checkout@v2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another action suggestion:
- name: Check Gitignored files
run: if [[ ! -z $(git ls-files -i --exclude-standard) ]]; then exit 1; fi
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this something that is likely to be an issue? What would a developer have to do to cause it?
@@ -108,6 +108,8 @@ public function add_fields( $item_id ) { | |||
|
|||
// Render the field. | |||
$this->render_field(); | |||
|
|||
return $item_id; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The method could use an update to introduce the new @return
value.
(New details: #814 (comment)).
This Pull Request migrates Fieldmanager's continuous integration runner to GitHub Actions. Along the way, it migrates the PHPUnit and PHPCS infrastructure to be Composer-based instead of Grunt-based, and it brings the PHP tests and linting back up to passing.
The highlights:
New minimum versions
The minimum supported versions of PHP and WordPress are now 7.4 and 5.8, respectively. (WordPress 5.9 is due in early 2022, and "supporting" 5.7 for the next couple of months didn't seem worthwhile.)
Migration of dependencies to Composer
Previously, PHPUnit was installed as part of setting up the virtual machine in Travis and called directly, and Grunt was used to initiate PHPCS. Both are now installed and run through
composer.json
for simplicity, closer alignment with Alley's internal practices, and because the JavaScript unit tests that have kept the Grunt config alive are in such disrepair that they're dragging the PHP checks with them.QUnit tests are disabled
See previous section. These haven't worked properly for such a long time that keeping them on seems disingenuous. They should be fixed, but someone needs to do that, and the rest of Fieldmanager needn't wait, I think.
New GitHub Actions workflows for running PHPUnit and PHPCS
PHPUnit runs against the latest version of WordPress, in single-site and multisite mode, on PHP 5.6, 7.4, and 8.0, a small reduction in coverage from the Travis workflow, which tested down to PHP 5.3 and WordPress 4.7.6, and up to WordPress trunk. This reduction is meant to reflect the slower pace of Fieldmanager development over the last couple of years, as well as the fact that the minimum PHP version for WordPress is now 5.6.
Migration to Alley Coding Standards
We have been using our own PHPCS ruleset since early 2020. Adopting it here brings consistency for developers internally and ensures that new Fieldmanager code reflects our standards.
A new PHPCS "baseline"
The WordPress coding standards have evolved quite a bit since our last heave to bring Fieldmanager in line as part of versions 1.2 and 1.1.
This PR again brings Fieldmanager into coding standards compliance through the use of a "baseline" provided by https://github.com/isaaceindhoven/php-code-sniffer-baseliner. The baseline provides
phpcs:ignore
comments for every current PHPCS violation, allowing the current code to pass without disabling files or sniffs for future code.After running the baseliner, I fixed the cosmetic violations and swapped in preferred functions (
gmdate()
,wp_json_encode()
) where appropriate. All otherignore
lines should be either rewritten versions of old-styleWPCS:
comments or longstanding Fieldmanager code that will be difficult to fix and certainly not in scope here, like loose-equality comparisons.