-
Notifications
You must be signed in to change notification settings - Fork 3
Feature - redesign library with first cycle of refactoring #27
Feature - redesign library with first cycle of refactoring #27
Conversation
First proposal, @mbraekman , for the redesign of the library. Feel free to give some feedback so I can make this better + bigger changes we can place in separate issues of course instead of pushing to this PR. |
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.
Just some minor questions or request to add some additional tests.
You're doing a good job!
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 looks like a great API from a consumer perspective, well done 🎉
I've added a bunch of comments and suggestions but mainly nitpicking or testing requirements.
Next to that, I think we can introduce a bunch of unit tests for:
- Verifing our converter is working
- Ensure parameter validation works for
LogicAuthentication
,LogicAppTriggerNotFoundException
&LogicAppClient
/// <param name="logicAppName">The name of the logic app resource running in Azure.</param> | ||
/// <param name="resourceGroup">The resource group where the logic app is located.</param> | ||
/// <param name="subscriptionId">The ID that identifies the subscription on Azure.</param> | ||
public LogicAppException( |
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.
We should always order from least to most specific meaning - subscription, resource group, logic app name, message
src/Invictus.Testing.Tests.Integration/LogicAppNotUpdatedExceptionTests.cs
Show resolved
Hide resolved
{ | ||
Guard.NotLessThanOrEqualTo(minimumNumberOfItems, 0, nameof(minimumNumberOfItems)); | ||
|
||
string amount = minimumNumberOfItems == 1 ? "any" : minimumNumberOfItems.ToString(); |
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.
Frankly, this still feels off. Both our methods relying on this provide 1 so we'll always use any
which is not correct if you ask me.
I'd say that, if you want all runs, you don't provide this property and poll for a given amount of time or so which uses another flow than pulling for one; no? They are different but yet use same exact approach/parameters.
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.
Isn't that a problem, since there could be an continuously amount of runs? And we're never sure if we have all runs. I think that's the reason why this was in the initial design.
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.
We could use a max timeout but if that's how it worked before then that's it 🤷♂️
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.
The polling-mechanisms should have a max timeout, so either it returns the given amount of runs or it returns what it found after the max interval expired.
But that should've implemented, so should be OK.
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, then I guess I have to add two different approaches on this.
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, @mbraekman , this is now changed to this two-system approach. Can you approve/reject on this new changes? Thanks.
/// Runs the current logic app resource by searching for triggers on the logic app. | ||
/// </summary> | ||
/// <exception cref="LogicAppTriggerNotFoundException">When no trigger can be found on the logic app.</exception> | ||
public async Task RunAsync() |
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.
It starts a Logic App without you having to worry about the trigger name; that's what I think based on the implementation.
Is that correct @mbraekman ?
Guard.NotNullOrEmpty(triggerName, nameof(triggerName)); | ||
|
||
_logger.LogTrace("Run the workflow trigger of logic app '{LogicAppName}' in resource group '{ResourceGroup}'", _logicAppName, _resourceGroup); | ||
await _logicManagementClient.WorkflowTriggers.RunAsync(_resourceGroup, _logicAppName, triggerName); |
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.
Then we should log that for sure :)
Sounds like a test going wrong, no? Can you help here @mbraekman ?
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.
Lost track of all the feedback but think most of it is said so giving a 👍 once you think everything is processed @stijnmoreels
Co-authored-by: Maxim Braekman <[email protected]>
Co-authored-by: Maxim Braekman <[email protected]>
Separate logic app "single instance" and "many instances" functionality
Functionality on a single logic app is placed in the
LogicAppClient
while the polling is moved to theLogicAppsProvider
.Introduce 'temporary' functionality
This makes sure the setup/teardown of logic app operations are more managed/controlled.
Building polling function
Reworked the different polling functions available in a more streamlined/fluent design.
Relates to #3