Open feedjosiah opened 1 year ago
I've already made the necessary changes in my local dev branch. Waiting for approval to make a PR. I'd really like this to get looked at, maybe I can buy you a cup of coffee and we hammer this out. Thanks
Hi @feedjosiah
We already have Telegram, Slack, email alerts. I sure it is right way to support new messengers but we should refactor alert mechanism. We can't extend configuration file with new options for each messenger. I think we should add configuration section for all messengers.
{
"alerts": {
"telegram": {},
"slack": {},
"email": {},
"google_chat": {},
...
}
}
@fiftin For the alert mechanism, it can be refactored to build a general alert struct and passed it to a generalized method for sending the alert. The specific alert template will determine what values are used from the alert struct. The caller could use sendAlertMessage("slack") or sendAlertMessage("email") to chose the correct template and execute each alert.
I'm not as familiar with the configuration/setup code. How do you anticipate the setup to behave with this new configuration? Will it still ask all the questions for each messenger?
@feedjosiah it is good question...
Setup process already too complex. I sure we should simplify it but not complicate. I think we should remove messengers configuration from setup process.
@fiftin what do you think of this for the scope:
@feedjosiah I like it :)
@fiftin Should I create a fork for this and use that in a pull request? Is that the proper procedure in this case?
I looked into the code a bit. the way the alerts are implemented can be difficult to add alerts. the only way to do something is to refactor the alerting mechanism.
The way we added alerts for our Discord server on our end is to rewrite the slack alert on the fly with benthos. This is because the current slack alert implementation asks for the full url instead of individual fields and send it to hooks.slack.com. Which means that you can give semaphore a url to an http proxy or an api gateway that rewrites the requests and forwards it. You can do the same with google chat I believe. Or even to rewrite github (or any scm) webhooks as ansible semaphore api calls to do the whole fancy CI/CD thing.
(not affiliated with any product mentioned here. this is just my homelab workflow/our workflow with my team in different project)
If we are maybe looking at refactoring alerts, can we also look into being able to add a proxy setting for those alerts. Not everything on the host needs to be proxied, for example via SQUID, but for internet access to certain endpoints, we would like to add SQUID Proxy.
In this instance, it would be nice if we could have something like alert_proxy_endpoint: "",
in the config at present.
Not to step on anyone's toes but, aren't slack alert are simple webhooks similar to google chat's webhooks? instead of using hardcoded slack alerts , can we change it to general webhook alert mechanism.
if anything i said is incorrect or inaccurate, correct me and let me know
Not to step on anyone's toes but, aren't slack alert are simple webhooks similar to google chat's webhooks? instead of using hardcoded slack alerts , can we change it to general webhook alert mechanism.
if anything i said is incorrect or inaccurate, correct me and let me know
True, but I am not sure if writing short term code debt is a good solution. The intention of @fiftin seems to refactor the whole alerting mechanism.
I have already started to build a PoC for the configuration. Initially I wanted to introduce more environment variables only, but maybe it makes sense to refractor the alerts as well.
Hi, I'd would like to create a pull request to add the ability for Semaphore to send GChat alerts. I read the docs about creating a PR and it says to create a issue here first. This feature comes down to just needing a different alert template. All the other logic used for the Slack alerts can still be used.