Use packer plugins install --path to install (development version)

[torarnv]

With modern Packer, and Packer templates with required_plugins sections, the plugins need to follow a specific folder structure and also come with a sha256 hash of the plugin.

By using packer plugins install --path we can let Packer deal with the specifics of installing a plugin from disk instead of from a repository.

[torarnv]

Need to tweak this a bit, hold on :)

[edigaryev]

Should we just update the GNUmakefile to have the same contents as it has in the scaffolding template (except for NAME and BINARY variables)?

[torarnv]

That would also work yepp :)

It doesn't have an install rule though, which would be nice to have, and the install rule shouldn't do go build -ldflags="-X '${PLUGIN_FQN}/version.VersionPrerelease=dev'" -o ${BINARY}.

One other thing I had to do was to update our version in version/version.go. I don't know if there's a way to keep it up to date whenever we tag/create new releases?

[torarnv]

One missing piece here is that Packer doesn't easily allow you to run a Packer template with required_plugins against a dev/pre-release version: hashicorp/packer#12749 (comment)

[torarnv]

Like this?

[torarnv]

We could adopt the entire GNUmakefile from the scaffolding repo as well of course, instead of cherry-picking changes, but that would require more updates outside of just the makefile. Not sure how much, but at least the PLUGIN_FQN part didn't work out of the box because we don't use the same format for our module declaration in go.mod

[torarnv]

One missing piece here is that Packer doesn't easily allow you to run a Packer template with required_plugins against a dev/pre-release version: hashicorp/packer#12749 (comment)

Looks like Packer just got the missing bits to support this use case :) See hashicorp/packer#12749 (comment)