[HPR-1138] Limit recursive plugin scanning to Packer plugin paths set by PACKER_CONFIG_DIR or PACKER_PLUGIN_PATH #12414
Conversation
nywilken
force-pushed
the
nywilken/plugin-scanning
branch
from
a0a5075
to
fd9c658
Compare
nywilken
changed the title
|
|
||
| pluginPaths, err = c.discoverSingle(filepath.Join(path, "*", "*", "*", fmt.Sprintf("packer-plugin-*%s", binInstallOpts.FilenameSuffix()))) |
There was a problem hiding this comment.
I presume this was the reason for the high number of syscalls? Globbing with this pattern will try to unravel a ton of subpaths before eventually finding the plugin(s) itself?
There was a problem hiding this comment.
That would check out with the history of the problem, since this change was introduced with v1.8.0 presumably
|
I see there's a TODO list on the description of the PR, is it planned to check all three before merging it, or is it for follow-up issues? |
Yeah, I plan to address these todos within this PR. I need to validate functionality and ensure docs reflect the correct plugin loading order. Thanks for the initial reivew. |
nywilken
force-pushed
the
nywilken/plugin-scanning
branch
2 times, most recently
from
bd28933
to
b746f50
Compare
nywilken
force-pushed
the
nywilken/plugin-scanning
branch
from
759ec69
to
ba36cf4
Compare
Packer will try to discover installed plugins in all of the directories defined by packer.KnowPluginFolders. In a previous release logic was added to scan nested directories in order to load plugins installed by `packer plugins install`. This change resulted in a nested directory scan for each folder within the KnownPluginFolders slice. This change reduces the nested directory scan to only the directories where plugins would have been installed using `packer plugins install`
* PACKER_PLUGIN_PATH takes precedence over all
nywilken
force-pushed
the
nywilken/plugin-scanning
branch
from
ba36cf4
to
172fab6
Compare
nywilken
added
backport/1.9.x
|
Merging to make available in the latest nightly. |
|
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. |
Packer will try to discover installed plugins in all of the directories
defined by packer.KnowPluginFolders. In a previous release logic was
added to scan nested directories in order to load plugins installed by
packer plugins install. This change resulted in a nested directoryscan for each folder within the KnownPluginFolders slice.
This change reduces the nested directory scan to only the directories
where plugins would have been installed using
packer plugins installCloses: #12405
Closes: #12352
This is sort of a breaking change as it changes how plugins are loaded but also not really as I think it works like this now but might be incorrectly documented 😄
TODO
Update documentation to reflect how plugins are scanned and loaded. The current docs are a little out of date.Opening in a separate PR.