I think the reason is so that you can edit event scripts in a text editor instead of the dashboard without restarting the node process every time
though that would be better done by watching the files for changes via fs.watch
Andrei Alecu
@andreialecu
deployd/deployd#384 this can be closed probably
Andrei Alecu
@andreialecu
deployd/deployd#480 any chance this could be merged soon-ish? It's innocent enough, only a testing infrastructure thing
and as with the phantomjs runner, it's very important to ensure code correctness, I keep having to merge it and test then revert
Andrei Alecu
@andreialecu
and by the way: deployd/deployd#476 , another positive side effect of the dpd cli change in this PR is that it tests if the cli works properly and can spawn a mongod instance. previously there were no tests for that - this at least ensures that npm test will fail if there is something wrong somewhere in /bin/dpd
Nicolas Ritouet
@NicolasRitouet
@andreialecu , I just rebased your PR, thx
Andrei Alecu
@andreialecu
just saw that, thx
I'm fixing something else I found, just caught it while working on my stuff
expect new PR
should be minor
Nicolas Ritouet
@NicolasRitouet
ok :sparkles:
Andrei Alecu
@andreialecu
deployd/deployd#485
is this squashable? I pushed to the same branch I used before instead of making another
in my case I could not actually login a user and retrieve it without crashing deployd without this fix. because my mongo is not on the same network as where I'm hosting my app
Andrei Alecu
@andreialecu
@ericfong or @NicolasRitouet , if you have production apps can you check db.sessions.stats()
the session handling in deployd is so rudimentary at this point that the table grows indefinitely and can even create a new session on every request without ever deleting any of them