rgl
commented
1 year ago Indeed, it should have aborted the provisioning.
The code needs to be improved to include some kind of tracing, to better identity which part of the code might have a broken flow. It seems that looking at the exit code is not sufficient to assume it succeeded (because in this case, it seems the exit code was 0, and the whole thing was considered a success).
At least, a message like "Operation finished with exit code XXX" should be added before the line at https://github.com/rgl/packer-plugin-windows-update/blob/34a14fede5d7d0548f50f0d30709a86cad6a4de4/update/elevated-template.ps1#L105. At least we would had a clue to whether is even reached the end of that script or something else aborted the script.
I'm having a problem with a new WSUS server - completely my issue, not really related to this provisioner - and when the client runs, it receives HRESULT exceptions, as it should. Where this relates to the provisioner is that somehow this results in a successful build!
In my packer template, I'm simply calling the provisioner with no updates:
In my build, the update step fails to ever get a positive response, but then the build goes on to succeed:
As mentioned, I know I have a problem with my new WSUS server, I would just like the provisioner to reflect that and fail the build.
I am using: packer 1.8 docker container hashicorp/packer:1.8 windows-update plugin 0.14.1