Add documentation about developper override

[remyleone]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Please search the existing issues for relevant feature requests, and use the
reaction feature
(https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/)
to add upvotes to pre-existing requests.

Description

I would like to have more documentation about how I can develop Packer plugins and have debugging workflows while debugging.

In terraform, it is possible to use: https://developer.hashicorp.com/terraform/cli/config/config-file
Is it also possible to use the same thing in Packer ? If not, is it possible to have a debugging workflows where I can attach a debugger with my IDE to test a given configurations?

Examples about how to set it up would be useful.

Use Case(s)

I'm a plugin developper and I would like to debug my plugin. I would like to attach a debugger to see the state of my variables.

Potential configuration

Potential References

In particular, could you add code examples on this page for the "Testing plugins" section?: https://github.com/hashicorp/packer/blob/main/website/content/docs/plugins/creation/index.mdx

[lbajolet-hashicorp]

Hi @remyleone,

Right now we unfortunately don't have a recommended workflow when it comes to having a gdb/delve attached to a process for step-by-step debugging, in my opinion the best way you can get something is to run your builds with --debug so that you get time to attach a debugger to the plugin process, link it to your IDE, and start debugging with this setup. Alternatively I would think you can use the debugger in CLI directly for debugging, but it's not a stellar experience I must say.
The workflow is a bit cumbersome unfortunately, Packer AFAIK will not tell you the PIDs of the plugin that's used, so I would suggest to ease your debugging experience by only using one component from the plugin in your templates, that way you can find it with something like pstree as a child of the packer process you have running, and there won't be multiple instances of the plugin running in the background.

Regarding the Testing plugins doc exerpt, I believe this is out-of-sync now, if you're using Packer v1.11.x for development, you can use packer plugins install --path to have a local version of your plugin to run tests with. If you've started from the scaffolding project you might have a make target: dev, which builds and installs the plugin automatically, then Packer should be able to load and use the plugin (I notice that the Scaleway plugin's Makefile does have that updated dev target, you should be good to go with it).

I was going to link hashicorp/packer-plugin-sdk#231 to this issue, but it seems you've already found it :)
@drewmullen had a similar question regarding debugging, I believe we encouraged him to essentially printf-debug (this is what we do internally for developing as well), but I wonder if he managed to get something to work for breakpoint debugging, if possible would you be able to share your findings? We can probably add some documentation exerpt for future users with that information.

Sorry to not bring better news to the table, hopefully we can improve that experience in the future.

[drewmullen]

hey all! yes I looked at this for a while. I dug for a day or so on attaching delve to a pid but... iirc... it wasn't feasible because each test runs many pids. blanking on some of the details...

We wound up using print debugging

If you figure it out please let me know!