Symfony 4 support #123
Symfony 4 support #123
Conversation
|
Not sure what's the failure about but that doesn't look like related 🤔 |
dunglas
force-pushed
the
symfony-4-support
branch
2 times, most recently
from
5330d8f
to
5e5d089
Compare
dunglas
force-pushed
the
symfony-4-support
branch
from
5e5d089
to
2890001
Compare
|
@stof failing tests seems to be unrelated... need to dig into another PR. |
sroze
force-pushed
the
symfony-4-support
branch
from
ef5c6f9
to
2890001
Compare
|
This failing tests are normal because they related to the |
|
Or... we just merge this PR 💃 |
composer.json
Outdated
| }, | ||
|
|
||
| "require-dev": { | ||
| "mink/driver-testsuite": "dev-master", | ||
| "symfony/http-kernel": "~2.3|~3.0" | ||
| "symfony/http-kernel": "~2.3|~3.0|~4.0", | ||
| "phpunit/phpunit": "^4.8.35|^5.7" |
There was a problem hiding this comment.
this requirement does not make sense if you use vendor/bin/simple-phpunit
There was a problem hiding this comment.
That's a good point. Removed.
|
Added the skip as you recommended Christophe... it feels very much hack. But I don't see how to detect any other way that the DomCrawler is the right version. |
|
All green 🎉 |
|
Any news on this :D ? This is blocking me from upgrading to SF 4.0 🙏 |
| 'testHtml5FormAction', | ||
| 'testHtml5FormMethod', | ||
| )) | ||
| && !method_exists('Symfony\Component\DomCrawler\Tests\FormTest', 'testGetMethodWithOverride') |
There was a problem hiding this comment.
Can't we find a method detecting relying on public classes instead ? test cases can be refactored in any patch release as they are purely internal.
There was a problem hiding this comment.
I know but I looked at finding another way and I can't, it didn't change :/
There was a problem hiding this comment.
I can't see any significant API changes for Browserkit 3.3 that we can latch onto
An alternative would be to use muglug/PackageVersions (or the upstream ocramius version if the PHP versions work out) in dev to explicitly detect the installed versions
There was a problem hiding this comment.
Or parse composer info in the travis bash, and set an env var etc. to be detected in the script
There was a problem hiding this comment.
Yup, seems much more complex options. The only sensible alternative (to me) would be a DISABLE_ACTION_ATTRIBUTES_TEST environment variable that we simply set in Travis for the "old" builds.
Replaces #121 and #122