There is currently a bit of a disconnect between how Beaker behaves when running tests and how interactive users are recommended to run commands through the "Start Windows Command Prompt with Puppet". That shortcut kicks off environment.bat, which sets up a number of environment variables:
- PATH - so that puppet.bat, facter.bat and friends are available
- RUBYLIB - so the search path for Ruby code includes the location of Puppet
- FACTER_env_windows_installdir fact - custom fact used by PE
- RUBYOPT set to automatically load rubygems (though this may no longer be necessary)
- SSL_CERT_FILE / SSL_CERT_DIR - to find additional certs - which fixes the
PA-620issue given we ship the CA that rubygems.org uses now
However, when Beaker initializes, it just modifies PATH, and it does it in a hacky-kind-of-way at:
This brings puppet.bat into PATH (and puppet.bat automatically invokes environment.bat, so Puppet itself will behave as expected). The problem is that if the users intent is to run another command (like the vendored Rubys gem.bat), then the environment will not have all variables included. We recently saw the manifestation of this in
PA-620, where an attempt was made to use the gem command on an old version of Ruby that has does not have the CA cert for the current rubygems.org.
We have workarounds locally for this problem (as the gem mirror we have uses a different CA that is included with old Ruby versions), but it's still possible that external users will have the same problem. This could also impact anyone developing modules with gem dependencies, where a gem install may be required in a pre-suite for instance.
I think fundamentally we can do a better job of making sure that the equivalent of environment.bat affects any commands issued by Beaker. There are more details at https://github.com/puppetlabs/beaker/pull/1278#issuecomment-260438569