Record start time of last started tasks

[dinoboff]

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.

[dinoboff]

That last test case in only meant to get 100% coverage (there must be a start event matching a stop or error event).

Maybe I should not test if _lastRuns[task] is set in the error and stop handler instead.

[dinoboff]

Looking at the integration test that fails on io.js:

• my implementation wouldn't work with that use case
• I don't know why they are not failing on nodejs too

[phated]

@dinoboff looks like you got it fixed, what was the problem?

[dinoboff]

@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.

[dinoboff]

@phated

Reading around:

• FAT32 time resolution is 2s
• Ext3 and HFS: 1s.
• NTFS: 100ms
• Ext4: < 1ms
• node fs stat time resolution is at most 1s in Node 0.10
• node fs stat time resolution is at most 1ms in Node 0.11+

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]

@phated What do you think?

[phated]

I dig it. I didn't know about these cases. Thanks!

[phated]

@dinoboff this PR is awesome. thanks for all the work and research put into this