Save screenshots of each site's final state

[alanchrt]

Each site should capture a screenshot after it's updated (or has an error) and the screenshots should be in a standard location on the system.

[kemaldaggen]

The predictable location could be

/screenshots/{date}/{pluginName}.png

[alanchrt]

Proposed solution from @cettox in #8.

[alanchrt]

Here are the things I'd like to consider:

1. Where on the system will the screenshots live when this is packaged for the npm registry? Do they live in the users's log directories?
2. Are screenshots on by default, or are they an optional CLI parameter?
3. Do we save screenshot history, or only the last state (error or success) for each adapter?
4. Should users be able to control the screenshot file destination?
5. Is there a good approach to dealing with screenshots that makes use of the user's ~/.passup.js file?
6. A user may use an adapter multiple times (ie. multiple google accounts), so the output must not only be unique to the adapter, but also to the account.

[alanchrt]

Here's what I'm thinking for now.

Screenshots will be off by default. If a user wants to enable them, they can do so in their ~/.passup.json file or at the command line. The CLI would look like this:

passup --screenshot-dir=~/logs/passup/

Or, if the user always wanted screenshots enabled, they could update their config like this:

{
    "screenshotDir": "~/logs/passup/",
    "passwords": [
        ...
    ]
}

Screenshots would be written out as PNGs after every step (every time a dot is printed to the console) and after errors occur. The naming convention would be like this:

[adapter]-[login].[step].png

Old screenshots would be overwritten on every write.

So, for a GitHub password update, the generated files would look like this:

~/logs/passup/github-alanctkc.1.png
~/logs/passup/github-alanctkc.2.png
~/logs/passup/github-alanctkc.3.png
~/logs/passup/github-alanctkc.4.png

This gives the user the chance to check and see what went wrong, and at which step.

@coalman, curious what your thoughts are on it! Does this make sense?

[coalman]

I think this is perfect for screenshots. However, I think it would be nice to have text-based log files too (incase I lose the output and I can't seem to replicate the error), but for the screenshot issue I think this is perfect.

[coalman]

Maybe every session that experiences an error should get it's own folder (for screenshots and a central log file to go in)?

I guess a log file isn't completely necessary. Might be overkill.

[alanchrt]

@coalman I think I could get behind the idea of a new directory for each session of screenshots. At first I was concerned this would bloat up disk usage, but then remembered that this isn't a script that runs daily, but probably every several months. That seems reasonable to have timestamped directories for each run.

Maybe there's some type of string interpolation we allow for configuration, and the default could be "${year}-${month}- ${day}/${hour}${minute}${second}/${adapter}-${login}.${step}.png", then we could allow the user to override it in their config. Not sure exactly what that format would look like (that's just an example), but that way, they could control the output a bit more.

A basic log file might be worth it. Just a timestamped list of update successes and failure messages. I could see how that would be valuable. If after a month, I forgot that one password update had failed and tried to log in, it might be helpful to check back and see that the adapter was broken or something had gone wrong.

[coalman]

I like the idea of allowing the user to configure the string interpolation. The only problem I see with that default format is if two of them are started in the same second (not sure why anyone would do this though). I think using timestamped directories with a log file could be worth while.

[alanchrt]

@coalman You know, maybe the simpler approach is just to have the default be ${timestamp}/${adapter}-${login}.${step}.png where ${timestamp} is a unix timestamp, then allow users to override if they want something prettier.

[alanchrt]

Here's a nice technique for extending String for named interpolation: http://stackoverflow.com/a/1408373

[coalman]

Yeah, I think that's the approach to use. Where would the logs go? I couldn't find a good way to resolve the user's home directory with casperjs.

Edit: I guess we could make it relative to the manifest path passed to init.js