Closed queglay closed 2 years ago
Hi @queglay,
Sorry for the late answer, I got sidetracked on that.
Regarding your problem, there are two possible solutions:
breakpoint
provisioner: the breakpoint provisioner essentially provides a point at which you can arbitrarily stop the build process to debug your build. This would perfectly suit a case like the first one you mention, where you know when to stop.
-on-error
flag: the on-error
flag lets you manipulate the behaviour of Packer when a problem occurs. By default it'll clean-up the resources, but you can change it (see packer build --help
for the complete list). ask
might be what you're looking for in this case, so when the build fails you can then jump-in and run any number of commands to help you debug.
Please let me know if these do not fit your situation, they suit most of the debugging needs of Packer users, but they're not perfect and it's always interesting to know if there's anything we can do to improve the experience, we can all benefit from this.
Thanks
Hi there :wave:, I'm going to close this issue since there hasn't been any updates to it. But if you are still running into issues please feel free to leave a comment on the issue and we will gladly reopen.
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.
Community Note
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
-Debug mode and having to hit enter line by line to get to just before the point of failure in a long build is more cumbersome than it could be, it requires to much manual interaction that is often totally unnecessary. I'd love to see an arg / mode that runs the build until a non zero exit code/exception occurs and provide a log in shell to probe the instance state only after the point of failure. This would speed up debugging and probing the instance state more rapidly than otherwise and we could more quickly iterate on our builds. Perhaps another not so great but still good alternative would be not not terminate the instance on failure, and the user could jump in themselves at that point.
Use Case(s)
Anytime there is a build issue that needs to be determined.