-
Notifications
You must be signed in to change notification settings - Fork 263
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
Fixing bug when looking up plugins on path with slash in argument #1415
Fixing bug when looking up plugins on path with slash in argument #1415
Conversation
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.
@psschwei: 0 warnings.
In response to this:
Description
Per discussion in PR 1412, found a bug where we fail to look up in path when there's slash in arguments. (This bug was also causing the service import test to fail).
Changes
- fixing bug when looking up plugins on path with slash in argument
(changelog entry to follow)
/lint
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
Codecov Report
@@ Coverage Diff @@
## main #1415 +/- ##
=======================================
Coverage 78.51% 78.51%
=======================================
Files 160 160
Lines 8283 8285 +2
=======================================
+ Hits 6503 6505 +2
Misses 1097 1097
Partials 683 683
Continue to review full report at Codecov.
|
@psschwei thansk! @rhuss as a lesson here, maybe it isn't a good idea to have file to path in |
As I'm writing a test, I have a question about what the assumptions are for plugin arguments. Take this example:
According to the logic in this PR, that would "find" a plugin called If it's the latter, then I think we'd need to update the logic some to parse the initial |
Yes, I believe this is already true with current implementation. I hope we may safely assume that there won't plugin sub-command with slashes in name. Handling of plugin name and arguments is done by the outer for-loop that's moving through params array and reducing it. I believe it should go like this.
|
Got it -- I think I was confusing the plugin lookup and actually executing the plugin :) |
Thanks for the fix & the test coverage @psschwei! @rhuss @maximilien can you please take a look? /lgtm |
pkg/kn/plugin/manager.go
Outdated
@@ -401,6 +401,10 @@ func findMostSpecificPluginInPath(dir string, parts []string, lookupInPath bool) | |||
var nameParts []string | |||
var commandParts []string | |||
for _, p := range parts[0:i] { | |||
// skip arguments with slashes | |||
if strings.Contains(p, "/") || strings.Contains(p, "\\") { |
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.
I don't think that you should just skip it, but completely stop the loop when the first part appears that can not be used as a plugin part, otherwise, you could call plugins accidentally, e.g.
kn myplugin not/possible bla
would also call an existing plugin kn-myplugin-bla
, but this is not following the plugin contract.
Also, you should ensure that you only filter characters that are not possible on the current OS filesystem. E.g. on UNIX you can have a backslash as part of a file name, so a plugin like kn-myplugin-ext\ra
is possible on UNIX (but not on Windows). So you should filter on the concrete file separator.
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.
Also, you should ensure that you only filter characters that are not possible on the current's OS filesystem. E.g. on UNIX you can have a backslash as part of a file name, so a plugin like
kn-myplugin-ext\ra
is possible on UNIX (but not on Windows). So you should filter on the concrete file separator.
+1 that's a great point.
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-to-test
pkg/kn/plugin/manager_test.go
Outdated
fmt.Println(tmpPathDir) | ||
|
||
createTestPluginInDirectory(t, "kn-path-test", tmpPathDir) | ||
pluginCommands := []string{"path", "test", "/withslash"} |
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 test should also use a os.PathSeparator
otherwise it will fail on Windows.
Also I would suggest to use a loop and multiple tests, e.g.
path test /withslash
path test /withslash extra arg
path test ext\ra (using something like `os.PathSeparator == '/' ? "\\" : "/"`)
bb380a8
to
5d1e08d
Compare
The following is the coverage report on the affected files.
|
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.
/approve
/lgtm
thanks !
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: psschwei, rhuss The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Description
Per discussion in PR 1412, found a bug where we fail to look up in path when there's slash in arguments. (This bug was also causing the service import test to fail).
Changes
(changelog entry to follow)
/lint