Hi,
The success of builds on Travis seems to hinge on a particular test case:
ext/standard/tests/file/disk_free_space_basic.phpt
It asserts that if a file is written to, the free space after the write
must always be lower than the previously recorded value.
On a busy system the free space is affected by many factors that can cause
this assertion to fail and thus developers get a nasty looking (X) on their
pull requests.
Can't we just assert that "the function returns a float, hurray!" instead?
--
Tjerk
Hi,
The success of builds on Travis seems to hinge on a particular test case:
ext/standard/tests/file/disk_free_space_basic.phpt
It asserts that if a file is written to, the free space after the write
must always be lower than the previously recorded value.On a busy system the free space is affected by many factors that can cause
this assertion to fail and thus developers get a nasty looking (X) on their
pull requests.
I actually committed a fix some time ago and didn't see a build of
PHP-5.5+ failing for that reason?
Regards,
Mike
Hi Mike,
On 27 September 2013 04:37, Tjerk Meesters tjerk.meesters@gmail.com
wrote:Hi,
The success of builds on Travis seems to hinge on a particular test case:
ext/standard/tests/file/disk_free_space_basic.phpt
It asserts that if a file is written to, the free space after the write
must always be lower than the previously recorded value.On a busy system the free space is affected by many factors that can
cause
this assertion to fail and thus developers get a nasty looking (X) on
their
pull requests.I actually committed a fix some time ago and didn't see a build of
PHP-5.5+ failing for that reason?
Ah, I just saw that you've changed the file size to 0xFFFF bytes now. The
fact that my topic branch is 2806 commits behind master probably has
something to do with that then ;-)
Rebasing my branch should fix it. Sorry for the noise!
Regards,
Mike
--
Tjerk
Hi Mike,
On 27 September 2013 04:37, Tjerk Meesters tjerk.meesters@gmail.com
wrote:Hi,
The success of builds on Travis seems to hinge on a particular test
case:ext/standard/tests/file/disk_free_space_basic.phpt
It asserts that if a file is written to, the free space after the write
must always be lower than the previously recorded value.On a busy system the free space is affected by many factors that can
cause
this assertion to fail and thus developers get a nasty looking (X) on
their
pull requests.I actually committed a fix some time ago and didn't see a build of
PHP-5.5+ failing for that reason?Ah, I just saw that you've changed the file size to 0xFFFF bytes now. The
fact that my topic branch is 2806 commits behind master probably has
something to do with that then ;-)
Now you said it... it fails again. :) Feel free to adjust this test to
be more robust.
Thank you!
On 27 September 2013 09:38, Tjerk Meesters tjerk.meesters@gmail.com
wrote:Hi Mike,
On 27 September 2013 04:37, Tjerk Meesters tjerk.meesters@gmail.com
wrote:Hi,
The success of builds on Travis seems to hinge on a particular test
case:ext/standard/tests/file/disk_free_space_basic.phpt
It asserts that if a file is written to, the free space after the
write
must always be lower than the previously recorded value.On a busy system the free space is affected by many factors that can
cause
this assertion to fail and thus developers get a nasty looking (X) on
their
pull requests.I actually committed a fix some time ago and didn't see a build of
PHP-5.5+ failing for that reason?Ah, I just saw that you've changed the file size to 0xFFFF bytes now. The
fact that my topic branch is 2806 commits behind master probably has
something to do with that then ;-)Now you said it... it fails again. :) Feel free to adjust this test to
be more robust.
Not sure if this counts: https://github.com/php/php-src/pull/484
I suppose you could argue that you could replace the whole implementation
by something that returns a random floating point value, but I reckon that
Travis is not the authority when it comes to release time, is it? :)
The only alternative I can see is to either compare its results with the
output of df (within error margins) or just make the file even bigger.
Not sure I like either of those ;-)
Thank you!
--
Tjerk