Feature/post 0.3.0 followups

[toddb]

Github issues closed

0.3.1

• Environment variable NOVU_API_KEY is not injected (as an override) #57
• INovuClientConfiguration is not exposed via DI service provider #58
• Remove Notification Templates as part of the API is now obsolete #59
• Separate out in DI the singleton Client from the explicit Clients #60
• Release Extensions and Sync dlls  #55

[toddb]

@wh1337 still need Novu.Extension and Novu.Sync packaged up and released to nuget.

the deploy and test scripts look a little off to me and happy to discuss. But really want/need the other packages released. Any chance?

[wh1337]

@toddb I can get those packaged up in a seperate PR shouldn't be an issue. It'll follow the same versioning as the main Novu package

[wh1337]

Reviewed, LGTM

[wh1337]

We are still seeing a failing test, which I would contribute to collision:
https://github.com/novuhq/novu-dotnet/actions/runs/5997551596/job/16270463765#step:9:47

@toddb review that and let me know if you agree

[wh1337]

Still see failling tests, please review and just let me know if it's because of collision with the novu api

[toddb]

@wh1337

I'm not sure what "collision" means here. Sounds like an accident! The integration tests of the Integrations do not do any destruction or creation so they won't be creating race conditions. There's a design issue that needs to be understood.The test shows that the novu in-app provider is a special singleton—at least from my perspective of how to model across HTTP/REST.

Hence why the original test had the assertion SingletonOrDefault rather than First. You'll probably also note that this is a Theory test and the change to first may be a better a approach, however, across all the providers when the test is completed.

There are two improvements required in the code. The first is already logged as #56 because the test has a magic string—that was a placeholder that others are able to build on. The second is more a fundamental design problem of the way the Refit library is wrapped—there is no wrapping layer in the client code that can make cater for the practical impedance mismatch between the API and the calling code—in this case error handling that aren't necessarily exceptions but rather logic errors.

Back to the test. So, the test assumes that a logical DELETE on a resource then allows for a POST. Hence it tests that the GET on the resource fails. It then does a passing POST. I managed to recreate the error (which didn't make sense) but now the tests don't. I added explicit lifecycle branches in the test code—I'm still a little at a lose to the underlying issue that looked like a timing issue.

[toddb]

@wh1337 @unicodeveloper

I have reworked the test and deploy scripts, documentation is inline in the scripts.

• The tests now have phases like a pipeline
• the deploy will create three packages (tested locally, you'll see in the script what is used).

There is an issue within one of the integration tests meaning that it hangs. I have paused that phase but left other check and balances in place.

[wh1337]

approved, will get this published as v0.3.1