feat: support skipping cache and storage clear #1675
Conversation
lighthouse-cli/bin.ts
Outdated
| @@ -65,6 +65,7 @@ const cliFlags = yargs | |||
| 'port' | |||
| ], 'Configuration:') | |||
| .describe({ | |||
| 'disable-cache-clearing': 'Disable clearing of cache and storage before the run', | |||
There was a problem hiding this comment.
other name ideas welcome, cache is more specific than what actually happens but is probably more familiar/understandable to users than a generic storage
There was a problem hiding this comment.
disable-storage-reset comes to mind. I actually think being more generic than "cache" is good for the reasons you mention. It applies to all forms of storage on the origin.
| }); | ||
| }); | ||
|
|
||
| it('does not clear the network cache and origin storage when flag is set', () => { |
There was a problem hiding this comment.
...when disable-storage-reset flag is set
lighthouse-cli/bin.ts
Outdated
| @@ -65,6 +65,7 @@ const cliFlags = yargs | |||
| 'port' | |||
| ], 'Configuration:') | |||
| .describe({ | |||
| 'disable-storage-reset': 'Disable clearing of cache and storage before the run', | |||
There was a problem hiding this comment.
nit: "Disable clearing the browser cache and other storage APIs before a run"
| @@ -91,13 +91,14 @@ class GatherRunner { | |||
|
|
|||
| static setupDriver(driver, options) { | |||
| log.log('status', 'Initializing…'); | |||
| const resetStorage = !(options.flags && options.flags.disableStorageReset); | |||
There was a problem hiding this comment.
is options.flags ever not defined here? If so, the options.flags.blockedUrlPatterns line below is in trouble
There was a problem hiding this comment.
oh yeah it probably always is, just was jumping around to other places where that wasn't true. i'll update
| calledDisableNetworkCache: false, | ||
| calledClearStorage: false, | ||
| }; | ||
| const createCheck = variable => () => { |
There was a problem hiding this comment.
it would be nice to replace fake-driver with a nice interface around something like this :)
There was a problem hiding this comment.
or we could use sinon :)
There was a problem hiding this comment.
yeah, I'd be fine with that too.
Honestly I hate these tests involving the driver. Rely too much on knowledge of internal implementation instead of externally observable behavior. If we're going to assume the driver calls made and the order they're made in, I'd rather we just setup a debugger protocol record/replay system :)
fixes #1664