CI: Prevent Jetpack Sync tests from colliding when running in parallel #45948
Conversation
tbradsha
added
[Status] Needs Review
|
Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.
Interested in more tips and information?
|
github-actions
bot
added
[Plugin] Jetpack
|
Thank you for your PR! When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:
This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖 Follow this PR Review Process:
If you have questions about anything, reach out in #jetpack-developers for guidance! Jetpack plugin: The Jetpack plugin has different release cadences depending on the platform:
If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack. |
Code Coverage SummaryCannot generate coverage summary while tests are failing. 🤐 Please fix the tests, or re-run the Code coverage job if it was something being flaky. |
| if ( ! static::$lockfile ) { | ||
| throw new RuntimeException( 'Failed to open lockfile ' . sys_get_temp_dir() . '/jetpack-sync-test.lock' ); | ||
| } | ||
| if ( ! flock( static::$lockfile, LOCK_SH ) ) { |
There was a problem hiding this comment.
If sync tests are failing because one test process modifies the filesystem (themes/plugins) while another test process reads it at the same time, then won't using LOCK_SH give both tests the lock at the same time?
The current test failure -TypeError: fclose(): supplied resource is not a valid stream resource - could imply that the resource was already closed.
So, should we:
- use an exclusive lock (
LOCK_EX), so only one process is holding it at a time - release the lock (
LOCK_UN) beforefclose()?
There was a problem hiding this comment.
LOCK_SH to LOCK_EX: Yes, definitely. I was playing with different flags in the last PR but it slipped through there and then into this PR. Thank you for catching it. 😄
release the lock
Per the documentation, the lock is released on fclose():
https://www.php.net/manual/en/function.flock.php
Closes MONOREP-226
Like done in #45851 and #45902 (which will probably be reverted), this adds the locking code to prevent parallel tests from colliding, but this time at a base class level.
See comment here: #45923 (comment)
Proposed changes:
Other information:
Jetpack product discussion
Does this pull request change what data or activity we track or use?
Testing instructions:
I haven't yet tested this, but presumably running multiple Sync-related tests at the same time should generate the lock file and things should take turns.