Closed dinoboff closed 9 years ago
Looking at the integration test that fails on io.js:
@dinoboff looks like you got it fixed, what was the problem?
@phated First I had to change the test. The original was testing that the built file by the task was older than the last task run time. With the pull request, the last task run time is the start of the task; the built file should always be younger than the last run time. I didn't know why it was only failing on iojs.
I changed the test to check that if a source file changes, using the since
option with lastRun, the unchanged source file would get filtered out. However the test needs to wait before modify a file to test it.
I think files' mtime and node time (or the time the extension before
method records) are not consistent. On my laptop (os x 10.9, node 0.10) mtime seems to get round dow to the second:
task setup started at 2015-03-17T12:10:04.347Z
task build started at 2015-03-17T12:10:04.355Z
task userWait started at 2015-03-17T12:10:04.362Z
task userEdit started at 2015-03-17T12:10:05.484Z
task countEditedFiles started at 2015-03-17T12:10:05.486Z
counting /Users/dinoboff/dev/undertaker/test/fixtures/tmp/testMore.js
mtime 2015-03-17T12:10:05.000Z
Note that the file get modified after 12:10:05.484Z, but its mtime is 12:10:05.000Z. Seems be the same for travis node 0.10
On travis nodejs 0.12, it's not as bad, but it's still inconsistent:
task setup started at 2015-03-17T12:14:23.087Z
task build started at 2015-03-17T12:14:23.101Z
task userWait started at 2015-03-17T12:14:23.108Z
task userEdit started at 2015-03-17T12:14:24.209Z
task countEditedFiles started at 2015-03-17T12:14:24.211Z
counting /home/travis/build/phated/undertaker/test/fixtures/tmp/testMore.js
mtime 2015-03-17T12:14:24.208Z
userEdit
Task starts at 12:14:24.209Z but the file mtime is 12:14:24.208Z.
On Travis iojs the task start time and the file mtime are the same.
@phated
Reading around:
I don't know if the issue with node 0.12 (mtime < start task in that travis run) is due to a bug with node 0.12, with travis container or with the extension before
method.
Should Undertaker
round down the last run time for consistency?
@dinoboff this PR is awesome. thanks for all the work and research put into this
The files used to compare to lastRun time might get updated during the execution of a task.
Instead of recording the stop time, Undertaker should record the start time, before something like gulp.src start to read the content of a file.