Closed entendu closed 6 years ago
Merged #9 into here because I like green check marks.
CR 👍
@dom do you have any QA tips for this?
@entendu this hasn't gotten touched for a year. dev_block :x: to stop polluting pulldasher.
You can read the readme and see how alertinator should now operate with this pull
un_dev_block 👍
I'm taking this over.
Will write up a QA instruction set!
Closing in favor of #11 (same commits, on a branch rather than entendu:master
)
A few of my assumptions based off #6:
Since checks are (ostensibly) already on a timer, I think it makes more sense to notify after X failures/Y successes.
The way that
check()
is implemented, this is a problem. The alert level is based on which Exception class is used (e.g.,AlertinatorWarningException
), and in the case of success, the exception is never thrown. I have some ideas for implementing a better exception architecture (which would fit naturally into #3). As it stands, my code will alert on check-function only.Implemented
Implemented as an Interface so someone could extend it to, say, mysql instead of the filesystem.
Somewhat annoying -- the message is defined when the Exception is thrown and as you know there is no
$e->setMessage()
method. I did some dirty business to help, but the messaging methods will have to be refactored to get the level of robustness you're looking for.This PR should be fully backwards-compatible. Unit tests are included and docs are updated.