Simplify Pre-built Binary Release Archive with Unified Filename?

hswong3i commented 3 years ago

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):

$ curl -skL -O https://github.com/hashicorp/packer-plugin-docker/releases/download/v0.0.7/packer-plugin-docker_v0.0.7_x5.0_linux_amd64.zip
$ unzip -o -d . packer-plugin-docker_v0.0.7_x5.0_linux_amd64.zip
Archive:  packer-plugin-docker_v0.0.7_x5.0_linux_amd64.zip
  inflating: ./CHANGELOG.md          
  inflating: ./README.md
  inflating: ./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):

$ curl -skL -O https://releases.hashicorp.com/packer/1.7.2/packer_1.7.2_linux_amd64.zip
$ unzip -o -d . packer_1.7.2_linux_amd64.zip 
Archive:  packer_1.7.2_linux_amd64.zip
  inflating: ./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.

$ curl -skL -O https://github.com/hashicorp/packer-plugin-docker/releases/download/v0.0.7/packer-plugin-docker_v0.0.7_x5.0_linux_amd64.zip
$ unzip -o -d . packer-plugin-docker_v0.0.7_x5.0_linux_amd64.zip
Archive:  packer-plugin-docker_v0.0.7_x5.0_linux_amd64.zip
  inflating: ./packer-plugin-docker

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.

.script-bootstrap-packer: &script-bootstrap-packer
  - |
    if ! [[ -x "$(command -v packer)" ]]; then
      curl -skL -O https://releases.hashicorp.com/packer/1.7.2/packer_1.7.2_linux_amd64.zip
      sudo unzip -qq -o -d /usr/local/bin packer_1.7.2_linux_amd64.zip
      rm -rf packer_1.7.2_linux_amd64.zip
      curl -skL -O https://github.com/alvistack/packer-plugin-docker/releases/download/v0.0.7/packer-plugin-docker_v0.0.7_x5.0_linux_amd64.zip
      sudo unzip -qq -o -d /usr/local/bin packer-plugin-docker_v0.0.7_x5.0_linux_amd64.zip
      rm -rf packer-plugin-docker_v0.0.7_x5.0_linux_amd64.zip
    fi

In case single unified binary filename used, we could simply unzip it into /usr/local/bin directly without additional rename ;-)

Potential configuration

Potential References

nywilken commented 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.

hswong3i commented 3 years ago

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 :-(

hashicorp / packer-plugin-docker