-
Notifications
You must be signed in to change notification settings - Fork 17
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
Private teamsMessage Type in SendWithContext Method #285
Comments
Hi @nikoksr,
I'm interested in testing that change. For your project, what command do you run to regenerate the mocks for the I'm not familiar with I see how you have it listed here: //go:generate mockery --name=snsSendMessageAPI --output=. --case=underscore --inpackage but since I don't see the same here: type teamsClient interface {
// ... I wasn't sure if that indicated that you handcrafted the file or if I was just overlooking something. From what I can tell I can see that this file is generated, so I just assumed that I was overlooking the steps for generating it. |
@atc0005 thanks for the quick response. Nice catch, that's got to be a leftover because I thought I had removed all those go:generate directives. We recently upgraded to the latest version of mockery which uses a config based approach (you can see the config at the root of the repo). Running Let me know if there's anything else, I can help you with. And thanks for taking a look at this. |
Thanks for that. I ran Test changes here in a fork of your repo: For simplicity I did the following:
The commits are messy (some unrelated changes included), log messages not so great, etc. I tried to deep link directly to relevant bits. After all changes the tests pass: $ go test -v ./service/msteams/
=== RUN TestMSTeams_Send
=== PAUSE TestMSTeams_Send
=== CONT TestMSTeams_Send
=== RUN TestMSTeams_Send/Successful_send_to_single_webhook
=== PAUSE TestMSTeams_Send/Successful_send_to_single_webhook
=== RUN TestMSTeams_Send/Successful_send_to_multiple_webhooks
=== PAUSE TestMSTeams_Send/Successful_send_to_multiple_webhooks
=== RUN TestMSTeams_Send/Teams_client_error
=== PAUSE TestMSTeams_Send/Teams_client_error
=== CONT TestMSTeams_Send/Successful_send_to_single_webhook
=== CONT TestMSTeams_Send/Teams_client_error
=== CONT TestMSTeams_Send/Successful_send_to_multiple_webhooks
--- PASS: TestMSTeams_Send (0.00s)
--- PASS: TestMSTeams_Send/Teams_client_error (0.00s)
--- PASS: TestMSTeams_Send/Successful_send_to_single_webhook (0.00s)
--- PASS: TestMSTeams_Send/Successful_send_to_multiple_webhooks (0.00s)
PASS
ok github.com/nikoksr/notify/service/msteams 0.010s From what I can tell exporting If nothing further needs adjusting in this project I'll plan to release that change as a follow-up (e.g., v2.12.0) to the upcoming v2.11.0 release. |
Hi @atc0005, you went above and beyond with that, thank you so much. Sounds great! Do I see it correctly that there's nothing I need to explicitly do to fix this issue? I'll refactor Notify's teams service accordingly once I checked this PR of yours and from what I can tell, the most breaking thing that changes is the URL pattern validation. Which would make this more of a user concern than mine, if I understand it correctly. |
Hi @nikoksr,
You're welcome.
Perhaps you didn't mean it that way, but I'd argue that's not a breaking change. The previous pattern validation behavior continues to work as before, only now an additional default pattern is applied to permit workflow connector URLs to validate alongside O365 connector URLs.
Now that you've looked over the changes and don't see any glaring omissions, I'll proceed with applying the necessary changes to the development branch and tag a pre-release so you and others can test further (if desired). Thanks for the feedback. |
Export the `TeamsMessage` interface type to better support abstracting/mocking the functionality of this library by dependent projects. The fields of the interface are intentionally not exported so as to help prevent future changes/improvements from breaking client code. This change is considered a non-breaking change as the support for creating message types compliant with this interface is unchanged. refs GH-285
New tag: |
This change fixes all places in the msteams service where we were still using deprecated parts of the provider library https://github.com/atc0005/go-teams-notify. This change uses a pre-release of go-teams-notify to verify full compatibility between Notify and go-teams-notify, as discussed here: atc0005/go-teams-notify#285 Regenerated the mock since the service interface changed. Fixed the tests accordingly. Everything passes, we should be good to go.
Created a PR in Notify where I successfully implemented the fixed teams service using v2.12.0-alpha.1. Will merge once it gets fully released. Please let me know if there's anything left to clarify. And thanks again for your quick help, Adam :) |
Export the `TeamsMessage` interface type to better support abstracting/mocking the functionality of this library by dependent projects. The fields of the interface are intentionally not exported so as to help prevent future changes/improvements from breaking client code. This change is considered a non-breaking change as the support for creating message types compliant with this interface is unchanged. refs GH-285
You're welcome. Thanks for the CC on that PR. It was good to see the full set of needed changes. Created a RC tag to invite/encourage feedback from others before tagging a stable release: |
Hi there, notify author here! We've been in contact before about a similar issue.
A recently opened, very friendly issue in Notify brought to my attention that the O365 connectors within Teams will be deprecated. Since notify is still using deprecated members of your library like
goteamsnotify.MessageCard
, I began with fixing this. While doing so I noticed some issues when trying to abstract theSendWithContext
method.The Issue
goteamsnotify.teamsMessage
appears to be a private type.Impact on Notify
The main problem we're facing is that we can no longer abstract and mock the teams library due to the private
teamsMessage
type. This is particularly important for Notify because we rely heavily on mocking for our testing strategy. With over 30 external messaging platforms integrated into Notify, conducting end-to-end tests for each one isn't feasible. Mocking allows us to effectively test our integrations without the need for actual external connections.This is the interface we used to use to abstract your teams library in Notify:
Now, if switching to the latest state of
go-teams-notify
, we'd have to do this:And at that point, we're trying to externally access a private member of your library which of course leads to a compile-time error:
While we could add a whole wrapper layer in Notify around your library to work around this issue, it would introduce a lot of complexity and make maintenance more challenging. I'd really like not to.
Possible Solutions
teamsMessage
publicPlease let me know if there's anything unclear and thank you for your continued maintenance of this project.
Cheers,
Niko
The text was updated successfully, but these errors were encountered: