In the current state, the alertmanager-irc-relay already sends minutely
IRC PINGs. This allows to check the IRC connection's health in protocol
without having to deal with specific TCP settings. However, even when
we are sending those PINGs, we don't process the server's PONGs or their
absence.
On one of my alertmanager-irc-relay instances, the time between the last
received PONG and the TCP read to fail was round about fifteen minutes.
All this time, the connection was already dead, but there was no attempt
to reestablish it.
The introduces changes keep book on the last received PONG and fails if
there was no new PONG within twice the pingFrequencySecs time. When
establishing a new connection during the SetupPhase, the current time
will be set as the last PONG's time to reset the time comparison.
handle nickserv identify requests instead of blindly issuing a message
when connected
this helps if nickserv's state is wiped and we are being asked to
re-identify
introduce a `nickserv_identify_patterns` config option. these patterns
are used to guess identify requests of the various nickserv implementations
Signed-off-by: Luca Bigliardi <shammash@google.com>
Use nonexistent irc server and empty channel list as default config
options to avoid unwanted surprises when testing the bot.
Addresses https://github.com/google/alertmanager-irc-relay/issues/5
Signed-off-by: Luca Bigliardi <shammash@google.com>
Add `use_privmsg` config option to deliver alerts with PRIVMSG instead
of the default NOTICE.
This addresses a use case described in
https://github.com/google/alertmanager-irc-relay/pull/1 .
Signed-off-by: Luca Bigliardi <shammash@google.com>
Use a more generic name as there is soon going to be support for PRIVMSG
(see https://github.com/google/alertmanager-irc-relay/pull/1 for
background).
This introduces a backward-incompatible change in the config file for
these two parameters:
- notice_template -> msg_template
- notice_once_per_alert_group -> msg_once_per_alert_group
I am not introducing the new parameters with a deprecation plan since
both parameters are relatively secondary to the core functioning of the
bot (and this is a free time project after all).
Signed-off-by: Luca Bigliardi <shammash@google.com>
