-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add support for opsgenie #73
Conversation
Codecov Report
@@ Coverage Diff @@
## main #73 +/- ##
==========================================
- Coverage 65.93% 62.32% -3.62%
==========================================
Files 56 65 +9
Lines 1371 1858 +487
==========================================
+ Hits 904 1158 +254
- Misses 386 576 +190
- Partials 81 124 +43
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, but I have added some feedback.
Thanks for the feedback. I won't have time within the next 2 weeks but I'll get back to it after that to fix those things. |
Co-authored-by: allcontributors[bot] <46447321+allcontributors[bot]@users.noreply.github.com>
Co-authored-by: allcontributors[bot] <46447321+allcontributors[bot]@users.noreply.github.com>
…channel (used to segfault) (containrrr#83) Co-authored-by: Simon Aronsson <[email protected]>
JSON is too generic. OpsGenie uses the term "payload" in their documentation so I've used that instead.
Shoutrrr uses the term `service` by convention
Hi All, I pushed changes that address the issues mentioned above. Apparently I also rebased wrong or something like that because I see a few commits that probably shouldn't be in this branch. What's your general policy here? I can fix this if you are ok with a force-push to this branch. Alternatively I could open a new PR. |
I would squash this anyway, so it should be fine! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A lot of great work has been put into this, but I'm not so sure about the raw JSON URLs.
Left some comments.
Alright, closing this for the time being then. We try to aim at only implementing services that people actually will use. If anyone actually wants/needs Opsgenie support, please open another ticket and let us know. Thanks for your contributions! |
Well, I'm using it, that's why I implemented the integration in the first place ;-) I'm happy to work on the remaining issues if you plan on merging it, just let me know. Until then, it works well enough for me as it is. |
I must have mixed issues together! I closed this because I was under the impression that you abandoned the idea of using shoutrrr for your project. Reopening. |
No worries, I know I'm sometimes a bit slow to respond. Especially around Christmas :-) |
Co-authored-by: nils måsén <[email protected]>
Co-authored-by: nils måsén <[email protected]>
I just pushed some changes. The service now works well with the Next I'll be working on integrating PropKeyResolver and replacing the raw json fields with more human readable format as suggested by @piksel. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work overall! The suggested changes are optional, but will increase the test coverage a bit if nothing else :)
Also; I merged the send ArraySlice
fix, so now you can correctly test using the CLI (if you rebase/merge main
)
I merged the changes in master. Problem is that
Btw. I found two unrelated issues: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work!
I will look into creating an interface for de-/serializing structs that the entities can implement.
If you move out the looping from the entity methods to a pair of:
(e *Entity) SetFromProp(propValue string) error { }
and
(e *Entity) GetPropValue() (string, error) { }
I will try to get it implemented ASAP
|
||
When("generating a config from a url with query parameters", func() { | ||
It("should populate the config fields with the query parameter values", func() { | ||
queryParams := `alias=Life+is+too+short+for+no+alias&description=Every+alert+needs+a+description&actions=An+action&tags=tag1,tag2&details=key:value,key2:value2&entity=An+example+entity&source=The+source&priority=P1&user=Dracula¬e=Here+is+a+note&responders=user:Test,team:NOC&visibleTo=user:A+User` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would make the test work with the encoded query field values:
queryParams := `alias=Life+is+too+short+for+no+alias&description=Every+alert+needs+a+description&actions=An+action&tags=tag1,tag2&details=key:value,key2:value2&entity=An+example+entity&source=The+source&priority=P1&user=Dracula¬e=Here+is+a+note&responders=user:Test,team:NOC&visibleTo=user:A+User` | |
queryParams := `alias=Life+is+too+short+for+no+alias&description=Every+alert+needs+a+description&actions=An+action&tags=tag1%2Ctag2&details=key%3Avalue%2Ckey2%3Avalue2&entity=An+example+entity&source=The+source&priority=P1&user=Dracula¬e=Here+is+a+note&responders=user%3ATest%2Cteam%3ANOC&visibleTo=user%3AA+User` |
The users won't have to escape all the characters, it will handle both, but the generated ones are at least ensured to always be valid URL query params.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok fixed. I misunderstood and thought you wanted to preserve the commas, etc. when generating urls.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you move out the looping from the entity methods to a pair of
Done, is that what you had in mind?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you move out the looping from the entity methods to a pair of:
That was one mess of a sentence. But yeah, exactly.
This avoids having to initialize PropKeyResolver twice (once when initializing and once when generating a playload)
Hey, I'm still aware of this and want to finally test it, just haven't had the time yet. It's not forgotten! |
Note that this does not affect how the keys are send to the service, just how we generate and parse URLs.
Ok , so I merged #137 and tested everything again. I also manually tested sending a bunch of differently configured alerts to OpsGenie. That worked as expected. Functionality wise I this is ready to be merged from my perspective. |
Yeah, exactly. This is kind of the same deal as with the commas etc. The generated URLs have the query values in alphabetical order, uses lowercase keys and are escaped. This is mainly for testing purposes, if the format is uniform and known beforehand, black box tests for the serialization is easier to write and update when something changes. I'll fix the CA issues and merge #137, hopefully this won't have any conflicts after that, in which case I'll merge this as well. Great job! |
Co-authored-by: Jonas Pfannschmidt <[email protected]>
Solved merge conflicts and merged as #140! Great job! 🎉 |
No description provided.