Tests break on WP `trunk` - `ls: cannot access - no such file or folder`
schlessera opened this issue · comments
The tests currently fail on WP trunk with the following error:
ls: cannot access /tmp/wp-cli-test-suite-cache-language-core.feature.4-5cb78382e69bd8.76370729/translation: No such file or directory
It seems to have for core language, plugin languages and theme languages.
Here's one example of where that is happening: https://travis-ci.org/wp-cli/language-command/jobs/521353616#L720
Related wp-cli/wp-cli#5192
It's weird that this only happens to trunk. I can't think of any changes there that might have caused anything in that regard.
The error message indicates that packages are not cached by WP-CLI for some reason, causing the translation folder not to be created in the first place.
Were there changes with the filesystem abstraction, maybe?
These classes haven't changed in almost a year except for documentation changes, at least at first glance.
Then, there was this change to the language upgrader recently: WordPress/wordpress-develop@4052571
Introduces
Language_Pack_Upgrader::clear_destination()to clear existing translations before installing new translations. Ensures that unused translations in JSON format are cleaned up.
Could be related to https://core.trac.wordpress.org/changeset/45262
Disables signature tests for Plugins, Themes, and Translations, leaving only core updates.
You mean the disabled signature tests or the whole signature thing in general?
If I understand correctly, WP added signature tests to translations as well, even though they should now be disabled.
That means the code path for downloading the translations must have changed for that too.
@schlessera I think you're right. In the current nightly build, signature verification in download_url() is on by default. https://core.trac.wordpress.org/changeset/45262 disabled it.
So perhaps we just need to wait for the newest nightly to be built and explicitly disable signature verification everywhere.
That core changeset changes some method signatures, so we might want to update our child classes accordingly.
Also, the code seems to silently swallow that signature verification error message / WP_Error, which we also might want to improve.
Also, the code seems to silently swallow that signature verification error message / WP_Error, which we also might want to improve.
I suspected something like that might be the case, and the ls being triggered on a non-existing directory is just a symptom of the error not being checked.
We should fix the error detection first.