Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I'm trying to get run-tests.sh working on Windows.
First step (this issue) is to auto-detect the PHP interpreter. Attached patch does this trick. Works for me on Windows Server 2003.
Next step (separate issue) is to find out why Drupal is invoked, but no tests are run at all.
Comment | File | Size | Author |
---|---|---|---|
#24 | run-tests-find-windows-php-executable-331580-24.diff | 775 bytes | das-peter |
#23 | run-tests-enhancements-331580-23.diff | 7.21 KB | das-peter |
#20 | simpleTestRunner_WindowsFix_XmlSupport.diff | 7.34 KB | das-peter |
#17 | run-tests-remove-auto-detect.diff | 2.92 KB | mooffie |
#7 | 331580-auto-detect-php.patch | 2.03 KB | boombatower |
Comments
Comment #1
sunMissed to add "/php.exe" to the auto-discovered path.
Tests also start to run this way - however, they seem to break after 17 secs.
Thanks to DamZ for pointing out this nonsense. ;)
Comment #3
lilou CreditAttribution: lilou commentedSee: #335122: Test clean HEAD after every commit and http://pastebin.ca/1258476
Comment #4
catchComment #6
sunWasn't able to test this yet, because, somehow, my PDO extension vanished from my CLI, so... ugh.
Comment #7
boombatower CreditAttribution: boombatower commentedThe script used to work without --php for me then the auto-detect was added and it messed it up. I checked it out and $_SERVER contains SUDO_COMMAND, not $_ENV so I added a case for that, although it can also be in ENV.
Merged with previous patch and changed title.
Comment #8
sunAt least the Windows part is RTBC. It still doesn't properly run any tests, but at least it finds PHP and is able to list all tests. I can execute a test group, a single test class, or all tests, but everything is executed in 0.00 secs. My first reaction, of course, was: woah, awesome! How fast is that?! Then I found out that it's really too fast. :-D Though not sure, why.
Comment #9
mooffie CreditAttribution: mooffie commentedMmmm....
There are quite a few bugs in 'run-tests.sh' related to its "shell interaction".
I prepared a patch yesterday, to make it work on Unix-like systems, but it's only now that I see you too have been investing some efforts in this (My fault, I'm mostly off-line and not aware of what's going on here...).
I don't want to extend this patch's scope (it will cause delay in committing it), so I'll wait till it gets in and then I'll open a new issue. (Unless the maintainer (boombatower?) instructs me otherwise.)
Could you please investigate this issue? Is your $_ENV empty?
Comment #10
boombatower CreditAttribution: boombatower commentedI consider this to be a bug, also make it clear this should get in. No reasons why I should have to specify my php location when it is in standard location, run path, etc.
As for #9:
My $_ENV is empty and $_SERVER is loaded.
Comment #11
mooffie CreditAttribution: mooffie commentedOn the other hand, this issue purports to deal with Linux too, so it seems I'm on-topic in pointing out further bugs in this "Make run-tests.sh find PHP" mechanism (and escpecially since boombatower touches this same code in his patch):
To fix this, code of the form
elseif (!empty($_ENV['_']))
sould be changed toelseif (!empty($_ENV['_']) && (strstr($_ENV['_'], $args['script']) === FALSE))
. Ditto forlist($php, ) = explode(' ', $_ENV['SUDO_COMMAND'], 2)
.Alternatively, we shouldn't give the false impression direct execution is possible.
$command = "$php ./scripts/{$args['script']} --url {$args['url']}";
should be changed to:
$command = "$php ./scripts/{$args['script']} --url " . escapeshellarg($args['url']);
Or else, when not explicitly providing a --url parameter, mysterious things happen because the starved `--url' eats up the next word (which happens to be '--php', so this bug is on-topic here).
Comment #12
mooffie CreditAttribution: mooffie commentedBTW, what's wrong with the following solution?
To completely remove the auto-detecting stuff. $php will be set by default to 'php'. If the user wants some other interpreter (or, if the php interpreter isn't in $PATH), she'll specify it explicitly with "--php /path/to/some/other/php".
Comment #13
boombatower CreditAttribution: boombatower commentedThat's how it was...I much prefer that as anyone with a normal config will be able to just use "php". For the life of me I have no idea why it was changed.
Comment #14
mooffie CreditAttribution: mooffie commentedI found the issue that introduced this auto-detecting feature and I see people want it, so removing it isn't an option.
Most of my negative feelings towards run-tests.sh stem from trying to execute it directly (e.g. ./run-tests.sh), but I see that it was never meant to be invoked this way. I'll later open a new issue to address this "documentation" problem.
So I'm reverting the status to what it was before I came here: "reviewed & tested by the community".
Comment #15
Dries CreditAttribution: Dries commentedI wouldn't mind to remove the auto-detect feature. Maybe we can use an environment variable that people can set if they are sick and tired of specifying --php. That is how Java does it. People can either specify the classpath or set $CLASSPATH.
Comment #16
boombatower CreditAttribution: boombatower commentedThe main problem with auto-detect...is (at the moment) it breaks on more peoples machines then without. So either "fix" with patch, or I think #15 is best.
Comment #17
mooffie CreditAttribution: mooffie commentedI was thinking about a variable that could contain any option, e.g.
$ export RUNTESTS_OPTS='--color --php /path/to/php'
, but tokenizing this string isn't very easy because /path/to/php may contain spaces.So here's a version that uses .ini file(s) instead.
(I'm marking this 'needs review' although I myself gave the code a very superficial check. sorry.)
Comment #18
cosmicdreams CreditAttribution: cosmicdreams commented#17: run-tests-remove-auto-detect.diff queued for re-testing.
Comment #20
das-peter CreditAttribution: das-peter commentedHi there,
I was struggling running the simpletests wit the run-test.sh script.
There are already several known issues. My patch should fix some of them.
Issues:
- Detecting php binary as described here: http://drupal.org/node/331580 this issue ;)
I've added a detection method for windows. But I'm sure it wont work for all environments
- Escaping command as described here: http://drupal.org/node/628498
I've fixed the escaping stuff - even spaces in path's are supported now. Most important part is to start the command with "cmd /C"
Enhancements:
- JUnit output file format - code from here: http://www.computerminds.co.uk/hudson-and-simpletest
I've ported the code to DP7 - and it runs with hudson like a charm :)
Feedback is highly welcome.
So long,
Peter
Comment #21
das-peter CreditAttribution: das-peter commentedTrigger autotests
Comment #23
das-peter CreditAttribution: das-peter commentedAnd another try - somewhere along the way it has to work :|
;)
Comment #24
das-peter CreditAttribution: das-peter commentedMore than a year later the story continuous :P
The only thing left of the patch seems to be the way how to find the php executable on windows. All the other stuff is fixed as fas as I can see after some smoke-tests.
Rerolled patch attached.
Comment #25
thedavidmeister CreditAttribution: thedavidmeister commentedJust closed out a related issuse as a duplicate #628498: run-tests.sh: escape shell arguments and improve documentation.