chore(cmp): refactor and test plugin discovery #20217
Conversation
Signed-off-by: Michael Crenshaw <[email protected]>
Signed-off-by: Michael Crenshaw <[email protected]>
Signed-off-by: Michael Crenshaw <[email protected]>
Signed-off-by: Michael Crenshaw <[email protected]>
🔴 Preview Environment stopped on BunnyshellSee: Environment Details | Pipeline Logs Available commands (reply to this comment):
|
✅ Preview Environment created on Bunnyshell but will not be auto-deployedSee: Environment Details Available commands (reply to this comment):
|
Signed-off-by: Michael Crenshaw <[email protected]>
Signed-off-by: Michael Crenshaw <[email protected]>
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #20217 +/- ##
=========================================
Coverage ? 55.98%
=========================================
Files ? 322
Lines ? 44569
Branches ? 0
=========================================
Hits ? 24951
Misses ? 17047
Partials ? 2571 ☔ View full report in Codecov by Sentry. |
|
@CodiumAI-Agent /review |
PR Reviewer Guide 🔍(Review updated until commit cf553e6)Here are some key observations to aid the review process:
|
| // check if the given plugin supports the repo | ||
| conn, cmpClient, connFound = cmpSupports(ctx, pluginSockFilePath, appPath, repoPath, fmt.Sprintf("%v.sock", pluginName), env, tarExcludedGlobs, true) | ||
| if !connFound { | ||
| c := newSocketCMPClientConstructorForPluginName(pluginSockFilePath, pluginName) |
There was a problem hiding this comment.
Not sure if I am understanding it correctly but this PR introduces the new CMPClientConstructor interface however it seems that it is impossible to use a different implementation than the socketCMPClientConstructor. Not sure if this was intentional, but it would be great if we could enable the flexibility to use different CMPClientConstructor implementations. This could help simplifying the CMP as a Service PR.
There was a problem hiding this comment.
it seems that it is impossible to use a different implementation
The only other implementation is the mock implementation used for testing.
The other option would have been to have (un)namedCMPSupports accept a getClient function, but the code just looked ickier. I could go either way.
Signed-off-by: Michael Crenshaw <[email protected]>
|
LGTM |
|
Persistent review updated to latest commit cf553e6 |
| // Deprecated: Use the IsDiscoveryConfigured field from the CheckPluginConfigurationResponse instead. Argo CD no | ||
| // longer uses an expensive MatchRepository service to determine if discovery is enabled. Instead, we | ||
| // make a relatively cheap pre-flight request to the CheckPluginConfiguration service. We'll leave this | ||
| // field here to avoid errors on mismatched repo-server and cmp-server versions. | ||
| bool isDiscoveryEnabled = 2; |
There was a problem hiding this comment.
Do we use a strict parsing mode for protobuf where unrecognized fields would trigger error?
Plugin discovery logic is complicated and has resulted in difficult to diagnose bugs.
This PR makes a few changes:
RepositoryResponse.IsDiscoveryEnabledfield. No code actually uses that field anymore since we do a pre-flight CMP request to determine whether it has discovery enabled.cmpSupportsintonamedCMPSupportsandunnamedCMPSupports. ReadingcmpSupportswas difficult, because thenamedPluginparameter implied more than the name suggested. Specifically, whennamedPlugin == false, we could assume that the app spec did not contain a plugin.name. By using two different functions with two different names, we make it very clear that one is for use when the plugin name is specified, and the other is used when the plugin name is not specified.unnamedCMPSupportsandnamedCMPSupports. I'd love to test all the way up toDetectConfigManagementPlugin, but I think that would require more mock logic than I'm comfortable with.