hashicorp / packer-plugin-scaffolding Goto Github PK

The goreleaser.yml file references a make ci-release-docs target that was removed from the GNUMakefile. It also references a docs.zip file that is no longer created afaict.

Somewhat relatedly, the release workflow uses the --rm-dist flag which has been deprecated since 2023-01-17 and now no longer works.

zen4:~/packer-plugin-lxdapi$ go version
go version go1.20.1 linux/amd64

zen4:~/packer-plugin-lxdapi$ packer-sdc --version
0.3.4

zen4:~/packer-plugin-lxdapi$ go generate ./builder/lxdapi
mapstructure-to-hcl2: lxdapi.[Config]: internal error: package "context" without types was imported from "packer-plugin-lxdapi/builder/lxdapi"
builder/lxdapi/builder.go:1: running "packer-sdc": exit status 1

Would appreciate pointers on how to get around this issue.

Attempting to import "github.com/hashicorp/packer-plugin-x" from any Builder, Provisioner, PostProcessor or Datasource will fail because it results in a circular import. Thus, it is impossible for code in a plugin to obtain it's own version number, if it follows this scaffold.

There should be a way for plugin code to obtain its own version through Prepare() or some other call.

I have a plugin created from this scaffolding, and ended up adding the following rules to the .gitignore:

**/packer_log*.txt
**/git_*test.pkr.hcl
crash.log
.docs
docs.zip

Reasoning:

• **/packer_log*.txt and **/git_*test.pkr.hcl match the files generated by a failed acceptance test run
• crash.log file is created when packer crashes
• .docs folder is now created by make generate, and it's my understanding that this is just for previewing locally and doesn't need to be checked in, though I might be misunderstanding how the plugin docs gets built into the website.
• docs.zip is a build artifact

IMO these should all be part of the scaffolding here.

For better understanding how to make a packer plugin it would be educative to have:

1. GitHub releases of this plugin.
2. A working example (e.g. in a example kind of directory) which could be used by packer init/packer build.
3. A github action workflow that actually uses the example to run packer to test run the plugin.

The GNUmakefile supplied with this project helpfully provides a dev target that builds the plugin and copies it to ~/.packer.d/plugins. However I am currently unable to get packer to use that generated version.

Here is what "packer-plugin-lxdapi describe" returns for me
{"version":"0.0.4-dev","sdk_version":"0.3.1","api_version":"x5.0","builders":["builder"],"post_processors":[],"provisioners":[],"datasources":[]}

Here is the output from packer when I try to use my plugin. You can see that it finds the plugin under "/home/dman/.packer.d/plugins/packer-plugin-lxdapi". However I cant seem to find a packer invocation / version specification where I could coax packer into using this locally built packer plugin over the ones that are uploaded from github.

Could you please clarify what the local development workflow for plugins should look like?

2023/02/20 04:05:38 [INFO] Packer version: 1.8.5 [go1.18.9 linux amd64] 2023/02/20 04:05:38 Old default config directory found: /home/dman/.packer.d 2023/02/20 04:05:38 [TRACE] discovering plugins in /usr/bin 2023/02/20 04:05:38 Old default config directory found: /home/dman/.packer.d 2023/02/20 04:05:38 [TRACE] discovering plugins in /home/dman/.packer.d/plugins 2023/02/20 04:05:38 [DEBUG] Discovered plugin: lxdapi = /home/dman/.packer.d/plugins/github.com/deepankarsharma/lxdapi/packer-plugin-lxdapi_v0.0.2_x5.0_linux_amd64 2023/02/20 04:05:38 [DEBUG] Discovered plugin: lxdapi = /home/dman/.packer.d/plugins/github.com/deepankarsharma/lxdapi/packer-plugin-lxdapi_v0.0.4_x5.0_linux_amd64 2023/02/20 04:05:38 [INFO] found external [builder] builders from lxdapi plugin 2023/02/20 04:05:38 [DEBUG] Discovered plugin: lxdapi = /home/dman/.packer.d/plugins/packer-plugin-lxdapi 2023/02/20 04:05:38 [INFO] found external [builder] builders from lxdapi plugin 2023/02/20 04:05:38 [TRACE] discovering plugins in . 2023/02/20 04:05:38 [INFO] PACKER_CONFIG env var not set; checking the default config file path 2023/02/20 04:05:38 [INFO] PACKER_CONFIG env var set; attempting to open config file: /home/dman/.packerconfig 2023/02/20 04:05:38 [WARN] Config file doesn't exist: /home/dman/.packerconfig 2023/02/20 04:05:38 Old default config directory found: /home/dman/.packer.d 2023/02/20 04:05:38 [INFO] Setting cache directory: /home/dman/.cache/packer 2023/02/20 04:05:38 Old default config directory found: /home/dman/.packer.d 2023/02/20 04:05:38 [TRACE] listing potential installations for "github.com/deepankarsharma/lxdapi" that match "0.0.4-dev". plugingetter.ListInstallationsOptions{FromFolders:[]string{"/usr/bin/packer", ".", "/home/dman/.packer.d/plugins"}, BinaryInstallationOptions:plugingetter.BinaryInstallationOptions{APIVersionMajor:"5", APIVersionMinor:"0", OS:"linux", ARCH:"amd64", Ext:"", Checksummers:[]plugingetter.Checksummer{plugingetter.Checksummer{Type:"sha256", Hash:(*sha256.digest)(0xc0001fab80)}}}} 2023/02/20 04:05:38 [TRACE] version "v0.0.2" of file "/home/dman/.packer.d/plugins/github.com/deepankarsharma/lxdapi/packer-plugin-lxdapi_v0.0.2_x5.0_linux_amd64" does not match constraint "0.0.4-dev" 2023/02/20 04:05:38 [TRACE] version "v0.0.4" of file "/home/dman/.packer.d/plugins/github.com/deepankarsharma/lxdapi/packer-plugin-lxdapi_v0.0.4_x5.0_linux_amd64" does not match constraint "0.0.4-dev"

After generating a new repo, Dependabot finds a number of CRITICAL and HIGH vulnerabilities...

Coming back on this, we should probably add some partials to the example docs, so users that adopt it will see how they're used.

Originally posted by @lbajolet-hashicorp in #108 (comment)