* used components that don't have a required_plugin block will make Packer 'implicitly' require those. These components are manually selected and commented for now.
* add tests
* docs
This change adds a simple hostname validation check to validate that a
plugins source address is github.com before continuing with the Get
call. An issue was encountered when using a hostname different from
github.com, where the getter would continue to pull a plugin from GitHub
even if the hostname was something like "example.com". See log details
below.
Before change
```
2021/02/16 12:49:41 [TRACE] fetching checksums file for the "0.0.2" version of the example.com/hashicorp/docker plugin in
"/home/wilken/.packer.d/plugins/example.com/hashicorp/docker"...
2021/02/16 12:49:41 [DEBUG] github-getter: getting "https://github.com/hashicorp/packer-plugin-docker/releases/download/v0.0.2/packer-plugin-docker_v0.0.2_SHA256SUMS"
2021/02/16 12:49:42 [TRACE] Ignoring remote binary packer-plugin-docker_v0.0.2_x5.0_linux_arm64.zip, wrong system, expected
2021/02/16 12:49:42 [TRACE] About to get: packer-plugin-docker_v0.0.2_x5.0_linux_amd64.zip
2021/02/16 12:49:42 [DEBUG] github-getter: getting "https://github.com/hashicorp/packer-plugin-docker/releases/download/v0.0.2/packer-plugin-docker_v0.0.2_x5.0_linux_amd64.zip"
```
After change
```
2021/02/16 13:36:32 [TRACE] for plugin example.com/hashicorp/docker found 0 matching installation(s)
2021/02/16 13:36:32 [TRACE] getting available versions for the the example.com/hashicorp/docker plugin
2021/02/16 13:36:32 [TRACE] &{%!q(*github.Client=<nil>) "packer-getter-github-1.7.0-dev"} getter could not get release: example.com/hashicorp/docker doesn't appear to be a valid github.com source address; check source and try again.
2021/02/16 13:36:32 [DEBUG] will try to install: []
2021/02/16 13:36:32 [INFO] (telemetry) Finalizing. no release version found for the example.com/hashicorp/docker plugin matching the constraint(s): ">=v0.0.2"
2021/02/16 13:36:32 waiting for all plugin processes to complete...
```
This changes wraps the plugin client start call with an anonymous function so that Packer starts a
new plugin for each occurrence of a particular plugin block.
Before only one subprocess was being created causing subsquent calls to fail as it was trying start
an already started plugin subprocess.
Before Change
```
???????: failed loading comment: error dial unix /tmp/packer-plugin358226172: connect: no such file or directory
2021/02/05 16:09:13 On error:
2021/02/05 16:09:13 Waiting on builds to complete...
2021/02/05 16:09:13 Starting build run: null.basic-example
2021/02/05 16:09:13 Running builder:
2021/02/05 16:09:13 [INFO] (telemetry) Starting builder
on examples/basic-example.pkr.hcl line 29:
(source code not available)
dial unix /tmp/packer-plugin358226172: connect: no such file or directory
???????: failed loading comment: error dial unix /tmp/packer-plugin358226172: connect: no such file or directory
2021/02/05 16:09:13 packer.test plugin: [INFO] communicator disabled, will not connect
2021/02/05 16:09:13 packer.test plugin: Unable to load communicator config from state to populate provisionHookData
on examples/basic-example.pkr.hcl line 38:
2021/02/05 16:09:13 packer.test plugin: Running the provision hook
(source code not available)
dial unix /tmp/packer-plugin358226172: connect: no such file or directory
???????: failed loading comment: error dial unix /tmp/packer-plugin358226172: connect: no such file or directory
on examples/basic-example.pkr.hcl line 42:
(source code not available)
2021/02/05 16:09:13 [INFO] (telemetry) Starting provisioner comment
dial unix /tmp/packer-plugin358226172: connect: no such file or directory
```
After change
```
null.basic-example: output will be in this color.
==> null.basic-example: ____ _
==> null.basic-example: | __ ) ___ __ _ (_) _ __
==> null.basic-example: | _ \ / _ \ / _` | | | | '_ \
==> null.basic-example: | |_) | | __/ | (_| | | | | | | |
==> null.basic-example: |____/ \___| \__, | |_| |_| |_|
==> null.basic-example: |___/
==> null.basic-example:
==> null.basic-example: Running local shell script: /tmp/packer-shell646549657
null.basic-example: This is a shell script
==> null.basic-example: Pausing at breakpoint provisioner.
==> null.basic-example: Press enter to continue.
==> null.basic-example: In the middle of Provisioning run
==> null.basic-example: Running local shell script: /tmp/packer-shell177279484
null.basic-example: This is another shell script
==> null.basic-example: _____ _
==> null.basic-example: | ____| _ __ __| |
==> null.basic-example: | _| | '_ \ / _` |
==> null.basic-example: | |___ | | | | | (_| |
==> null.basic-example: |_____| |_| |_| \__,_|
==> null.basic-example:
Build 'null.basic-example' finished after 1 second 32 milliseconds.
==> Wait completed after 1 second 32 milliseconds
==> Builds finished. The artifacts of successful builds are:
--> null.basic-example: Did not export anything. This is the null builder
Please enter the commit message for your changes. Lines starting
```
This adds the new `required_plugins` block to be nested under the packer block.
Example:
```hcl
packer {
required_plugins {
aws = {
version = ">= 2.7.0"
source = "azr/aws"
}
azure = ">= 2.7.0"
}
}
```
For example on darwin_amd64 Packer will install those under :
* "${PACKER_HOME_DIR}/plugin/github.com/azr/amazon/packer-plugin-amazon_2.7.0_x5.0_darwin_amd64"
* "${PACKER_HOME_DIR}/plugin/github.com/hashicorp/azure/packer-plugin-azure_2.7.0_x5.0_darwin_amd64_x5"
+ docs
+ tests
* move maps of plugins back in core
* go mod vendor
* more fixes
* fix imports
* Update core_test.go
* fix build
* more fixes
* more fixes
* up vendors after fixing sdk
* Update post_processor_mock.hcl2spec.go
* Leave implementatino of MapOf in the sdk for plugi tests
Other wise use the interface
* go mod tidy
* add MapOfDatasource type too
This add :
* discovery of `packer-plugin-*` binaries from the known folders and ask them to describe themselves
* tests
For testing: in go we create a bash script that in turn calls back to Go. I could not make the tests to work on windows and then would like to postpone testing this for when we know more about the finite layout of this feature. That is mainly: how things are going to work with init, versioning and such.
Adrien Delorme
Dom Del Nano
Megan Marsh
Wilken Rivera
Adrien Delorme
Sylvia Moss