-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
add pkr plugin check cmd from packer core #85
Conversation
also remove deps to packer core
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 great. I like the approach of checking the describe output. In the future we might be able to extended it a bit to catch any potential name issues. For example some plugin not using plugin.DEFAULT_NAME for a single component.
Nice work.
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.
When testing against a built plugin not in my GoPath I get an error.
~> tree
├── packer-plugin-azure
├── packer-plugin-upcloud_v1.2.0_x5.0_darwin_amd64
└── packer-sdc
~> ./packer-sdc plugin-check packer-plugin-upcloud_v1.2.0_x5.0_darwin_amd64
2021/10/08 12:09:50 failed to describe plugin: exec: "packer-plugin-upcloud_v1.2.0_x5.0_darwin_amd64": executable file not found in $PATH
When we execute describe we might need to determine the absolute path of the binary.
Co-authored-by: Wilken Rivera <wilken@hashicorp.com>
Good catch, that's weird, I wonder why. It's fixed using the absolute path. |
This is simplified to not pull in core as a dep. The drawback is that we don't actually start plugins to verify that it works with Packer and has a
ConfigSpec
func. We do start a binary though.But I think this is fine since if a plugin implements describe then we can be pretty sure it uses the SDK's function and interfaces.
Related to hashicorp/packer#11317
closes hashicorp/packer#11309