First I'd like to say "Thank you" 🙇 Packer is a really helpful tool and expands infrastructure as a code to the new horizons.
Packer provides a wonderful debugging capabilities with -debug
flag. It stops and ask to press enter at each step of the build, provision and post-processing phases. What would be nice to add is kind of focus
metadata support, which allows skipping (not to stop and wait for pressing enter to continue) all steps till focused one. Let me give you an example:
...
"provisioners" : [
{
"type" : "shell",
"execute_command" : "sudo -S sh -c -x '{{ .Vars }} {{ .Path }}'",
"script" : "a.sh"
},
{
"type": "shell",
"execute_command": "sudo -S sh -c -x '{{ .Vars }} {{ .Path }}'",
"script": "b.sh"
},
{
"focus": true,
"type": "shell",
"execute_command": "sudo -S sh -c -x '{{ .Vars }} {{ .Path }}'",
"script": "c.sh"
},
...
runs a.sh
and b.sh
without any interuption, but c.sh
requires to press enter to continue.
This option could save some time on pressing enter till the section devops engineer needs to debug.
The last thing I'd like to mention packer
provides -on-error=ask
flag, which does something similar to what I want to suggest, but the breakpoint is determined by the error. Of course, we may introduce an error at the place of interest intentionally, but I think it's not a proper way to debug ^_^
Does it make sense?
P.S. The idea of the focus
metadata is inspired by rspec inclusion filters.
This is a cool idea and would definitely improve the debugging experience.
Thinking about this in relation to Packer's architecture -- I think it would be easiest to implement as its own provisioner.
"provisioners" : [
{
"type" : "shell",
"script" : "a.sh"
},
{
"type": "debug-breakpoint",
}
{
"type": "shell",
"script": "b.sh"
},
]
I've implemented this in the linked PR -- if you'd like to give it a whirl, let me know what your host OS is and I can build you a binary for testing.
@SwampDragons Thank you very much 🙇
I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
Most helpful comment
This is a cool idea and would definitely improve the debugging experience.