RFC: Extending a Builder by adding new metadata keys

[svmastersamurai]

Hi, I'm trying to extend the QEMU builder in Packer to accomodate my environment:
I am building on a server that does not have VNC and the configuration is unsupported by our sysadmins. I build locally to verify that they work in headless, and want to offload the actual builds to our beefier servers. I am trying to add new options that will skip over the VNC portion since I do not need to enter any boot commands after the boot, but when appending them I am always met with an 'unknown configuration key' after I add my changes.

I have made a gist that shows simplistically what I'm trying to accomplish: https://gist.github.com/svmastersamurai/6e6511859623c9178b5f

I did peruse the helper/decode.go source file and found that if I were to change the key to packer_anything then the decoder will flag it as valid and skip over, but that doesn't seem like a reasonable solution to get past the parsing error.

It could be I need to add in the metadata into another file somewhere, but I figure I'd ask some of you guys that are more familiar with the codebase :)

[cbednarski]

I applied your change and this is working for me. Did you run make dev or go build afterward? You may have recompiled the main packer executable but not recompiled the qemu plugin. Until #2608 lands you will need to use make dev to recompile packer and all the plugins.

[svmastersamurai]

@cbednarski thanks for the quick reply! 🍻
Strange, I was invoking 'make dev' to compile the binaries and ran into this every time. #2608 looks pretty badass though, I was curious why everything was compiled separately as opposed to one binary.

I'll jog home and double-check my build process and post an update. I'll also give your diff a patch too and check it out and see if that might fix my problem.

[svmastersamurai]

I set up one of my laptops with a fresh install of go and made my changes and got it to compile cleanly, and then changed the template. Surprisingly it worked. Took a look at the setup I had and compared it to the one on the server and noticed that my checkout from github on the server was its own separate directory. E.G.
$GOPATH/packer
as opposed to $GOPATH/src/github.com/mitchellh/packer

On the server I moved my development directory into the expected path that go has when you do a 'go get ' command and then rebuilt. Success!!

Looks like when I called the binaries it was pointing to the old versions like @cbednarski mentioned, so moving the working copy of git in to the structure go was expecting was the solution that worked for me.

[cbednarski]

Ah yes, $GOPATH/packer will definitely break go build. I've found the easiest way to clone the repo is using go get github.com/mitchellh/packer, which puts it in the right place. Thanks for following up!