Closed hswong3i closed 3 years ago
Hi thanks for reaching out. There is a mix of expected and unexpected behaviors in this last release so thank you for calling it out.
Shall we simplify our release archive content into single unified binary filename for simpler CI/CD/Scripting integration (i.e. packer-plugin-docker), e.g.
The name of the binary is intentional as it requires additional information needed to work and validate against Packer init. It is not something we can change at this time, as binary names are optimized for packer init. However, we can make sure that only a single binary is included in the zip file.
With https://github.com/hashicorp/packer-plugin-docker/releases/tag/v0.0.7 release archive, the unzip result with multiple files and non-unified binary filename (i.e. packer-plugin-docker_v0.0.7_x5.0_linux_amd64):
The inclusion of README and CHANGELOG is not expected so we will take a look at this to see what is going on.
From https://www.packer.io/docs/plugins#installing-plugins
The easiest way to manually install a plugin is to name it correctly, then place it in the proper directory. To name a plugin correctly, make sure the binary is named packer-plugin-NAME. For example, packer-plugin-amazon for a "plugin" binary named "amazon". This binary will make one or more components available to use. Valid types for plugins are down this page.
In case the _v0.0.7_x5.0_linux_amd64
suffix exists, doesn’t means if I directly extract them into /usr/local/bin
, we are expecting multiple version of plugin will be co-existed (IMHO, now the folder looks polluted...), where packer also able to catch the latest version for use correctly?
P.S. another side concern is, we don’t have packer plugin list
(which similar as vagrant plugin list
) for debugging, yet. I couldn’t confirm and verify rather my newly installed plugin are loading in by packer correctly :-(
Description
With https://github.com/hashicorp/packer-plugin-docker/releases/tag/v0.0.7 release archive, the unzip result with multiple files and non-unified binary filename (i.e.
packer-plugin-docker_v0.0.7_x5.0_linux_amd64
):In case of https://github.com/hashicorp/packer/releases/tag/v1.7.2 itself, the unzip goes into single unified binary filename (i.e.
packer
):Shall we simplify our release archive content into single unified binary filename for simpler CI/CD/Scripting integration (i.e.
packer-plugin-docker
), e.g.P.S. I temporarily fork the repo and re-zip it for following use case demo:
Use Case(s)
In my GitLab CI pipeline I will install packer if required (see https://github.com/alvistack/vagrant-gitlab-runner/blob/d77a233e61eff4c758b610352be04b55809c8d9d/.gitlab-ci.yml#L8-L17), e.g.
In case single unified binary filename used, we could simply unzip it into
/usr/local/bin
directly without additional rename ;-)Potential configuration
Potential References