When building projects against Windows targets, it can be a little tricky to debug them and can take a long time to re-run and verify that a fix worked. These are a few helpful workflows for testing changes more quickly (and apologies in advance for the word-vomit).
Often when debugging failed builds you'll want to use the following workflow:
- Run the build and print the output to a file:
bundle exec build <platform> [hostname] > vanagon-output
- Either use a remote desktop client to RDP into the host, or use SSH to start a cygwin shell
- Debug failures. This will depend on what kind of errors you're getting, but most likely will involve
Once you've built against a target once, you can edit any environment variables or files needed and manually rebuild just the failed dependency on the target. This provides a much faster workflow for verifying fixes than rebuilding the entire project.
- Make sure you've already built the project against the target at least once
- Either in terminal scroll back or in the vanagon-output file, find where the
GEM_HOME
,PATH
, and any other environment variables are exported when building the gem that's failing. - Copy those declarations and in a cygwin shell (either via SSH, or by opening a new cygwin shell in your RDP session) paste them.
cd
to the path where the failing gem dependency is, most likely/cygdrive/c/ProgramFiles64Folder/Puppet Labs/Bolt/lib/ruby/gems/2.7.0/gems/<mygem>
or something along those lines.- Run
make
- Profit.
If your changes primarily affect the environment variables Vanagon sets, you can use bundle exec inspect <platform>
to see changes to those variables and ensure everything is being set correctly.
This can be much quicker than doing a whole new build.
To rerun Vanagon against the same machine (which is already allocated and provisioned), you'll want
to remove the C:\ProgramFiles64Folder
directory from the target machine then rerun bundle exec build
. This directory is created by Vanagon during the build process, and is where gems are
compiled.