One of the things at work that I jointly manage is our fleet of CI/CD build servers.
Many years ago, back in the dark ages, the way we managed these was that we had a single master image, and we would clone that VM to build out the fleet. If we needed to make a change, we would apply the change to the master image, and then deploy clones of the new master.
About 12 months ago, we changed this process slightly by using Packer to automatically build the master image from scratch with scripts. This has several distinct advantages, including having source control history of changes, a library of installation scripts, and not having old or intermediate software components lying around as the installed software get upgraded or replaced.
Unfortunately, sometimes installers fail, particularly when I'm trying to add some complex new tool to the build servers. Packer's failure mode is to delete the entire VM, which means that I lose access to Windows Event Logs, textual logs, and I also can't try out alternative command-line arguments etc. without sitting through the Operating System installation and all previous scripts again.
To work around this, I stole a trick from AppVeyor's documentation. If I can make Packer wait indefinitely, and leave a manual trigger around so that I can force it to resume, then I can poke around the VM to my heart's content and have Packer either resume successfully, or handle failure and clean up the entire VM.
The method I settled on was quite simple. By inserting the following into the relevant PowerShell script that I want to debug:
New-Item C:\Pause.txt -ItemType File | Out-Null
Write-Host 'Sleeping...'
Do { Start-Sleep -Seconds 1 } While (Test-Path C:\Pause.txt)
Write-Host 'Resuming...' This creates a file called C:\Pause.txt and waits until I delete the file. This gives me time to connect to the VM console, log in, and poke around. When I'm done, I just delete the file, and Packer takes back control and continues doing it's thing.
