Skip to content

chore(cmp): refactor and test plugin discovery#20217

Open
crenshaw-dev wants to merge 7 commits intoargoproj:masterfrom
crenshaw-dev:test-cmp-discovery
Open

chore(cmp): refactor and test plugin discovery#20217
crenshaw-dev wants to merge 7 commits intoargoproj:masterfrom
crenshaw-dev:test-cmp-discovery

Conversation

@crenshaw-dev
Copy link
Copy Markdown
Member

@crenshaw-dev crenshaw-dev commented Oct 3, 2024

Plugin discovery logic is complicated and has resulted in difficult to diagnose bugs.

This PR makes a few changes:

  1. Deprecate RepositoryResponse.IsDiscoveryEnabled field. No code actually uses that field anymore since we do a pre-flight CMP request to determine whether it has discovery enabled.
  2. Break cmpSupports into namedCMPSupports and unnamedCMPSupports. Reading cmpSupports was difficult, because the namedPlugin parameter implied more than the name suggested. Specifically, when namedPlugin == 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.
  3. Make the CMP client constructor mock-able. It requires some code overhead, but discovery is so deeply entangled with CMP server API calls that I think it's worth it.
  4. Test the behavior of both unnamedCMPSupports and namedCMPSupports. I'd love to test all the way up to DetectConfigManagementPlugin, but I think that would require more mock logic than I'm comfortable with.
  5. Use securejoin instead of our internal path traversal detection logic - it's more robust.

Signed-off-by: Michael Crenshaw <350466+crenshaw-dev@users.noreply.github.com>
Signed-off-by: Michael Crenshaw <350466+crenshaw-dev@users.noreply.github.com>
Signed-off-by: Michael Crenshaw <350466+crenshaw-dev@users.noreply.github.com>
Signed-off-by: Michael Crenshaw <350466+crenshaw-dev@users.noreply.github.com>
@bunnyshell
Copy link
Copy Markdown

bunnyshell bot commented Oct 3, 2024

❗ Preview Environment undeploy from Bunnyshell failed

See: Environment Details | Pipeline Logs

Available commands (reply to this comment):

  • 🚀 /bns:deploy to redeploy the environment
  • /bns:delete to try again to remove the environment

@bunnyshell
Copy link
Copy Markdown

bunnyshell bot commented Oct 3, 2024

✅ Preview Environment created on Bunnyshell but will not be auto-deployed

See: Environment Details

Available commands (reply to this comment):

  • 🚀 /bns:deploy to deploy the environment

Signed-off-by: Michael Crenshaw <350466+crenshaw-dev@users.noreply.github.com>
Signed-off-by: Michael Crenshaw <350466+crenshaw-dev@users.noreply.github.com>
@codecov
Copy link
Copy Markdown

codecov bot commented Oct 3, 2024

Codecov Report

Attention: Patch coverage is 79.48718% with 16 lines in your changes missing coverage. Please review.

Please upload report for BASE (master@b2091e3). Learn more about missing BASE report.
Report is 1 commits behind head on master.

Files with missing lines Patch % Lines
util/app/discovery/discovery.go 76.47% 11 Missing and 5 partials ⚠️
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.
📢 Have feedback on the report? Share it here.

@crenshaw-dev crenshaw-dev marked this pull request as ready for review October 3, 2024 19:11
@crenshaw-dev crenshaw-dev requested a review from a team as a code owner October 3, 2024 19:11
@crenshaw-dev
Copy link
Copy Markdown
Member Author

@CodiumAI-Agent /review

@QodoAI-Agent
Copy link
Copy Markdown

QodoAI-Agent commented Oct 3, 2024

PR Reviewer Guide 🔍

(Review updated until commit cf553e6)

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 4 🔵🔵🔵🔵⚪
🧪 No relevant tests
🔒 No security concerns identified
⚡ Recommended focus areas for review

Refactoring
The refactoring of the DetectConfigManagementPlugin function to improve modularity and testability is significant. Ensure that the new structure does not introduce any regressions or misunderstandings about how plugins are detected and managed.

Logic Change
The changes in how discovery is handled (removing isDiscoveryEnabled and using isSupported only) could affect existing functionality. Verify that these changes align with the intended use cases and do not negatively impact existing workflows.

// 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)
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown

@pradithya pradithya left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if the e2e test include plugin by default?

Signed-off-by: Michael Crenshaw <350466+crenshaw-dev@users.noreply.github.com>
@pradithya
Copy link
Copy Markdown

LGTM

@QodoAI-Agent
Copy link
Copy Markdown

Persistent review updated to latest commit cf553e6

// 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;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we use a strict parsing mode for protobuf where unrecognized fields would trigger error?

@AJChandler AJChandler mentioned this pull request Nov 20, 2024
14 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants