(MODULES-2634) Verify try/catch with PowerShell module

[jpogran]

Due to the changes from MODULES-2962, ticket MODULES-2634 is fixed
as a side effect. Besides the module itself using try/catch semantics
in a templated PS1 file, it supports any kind of syntax or formatting.

This commit adds a unit test and an acceptance test to ensure that this
is the case.

[ferventcoder]

   should handle a try/catch successfully

hjnfofvp9ah46dr.delivery.puppetlabs.net (win2012r2) 17:20:06$ cygpath -m $(mktemp -t apply_manifest.pp.XXXXXX)
  C:/cygwin64/tmp/apply_manifest.pp.J1Ipm2

hjnfofvp9ah46dr.delivery.puppetlabs.net (win2012r2) executed in 0.29 seconds
localhost $ scp /var/folders/pg/45bzltkn4wg8kqpllxgzcjcr0000gp/T/beaker20160523-85801-yfz10j win2012r2:C:/cygwin64/tmp/apply_manifest.pp.J1Ipm2 {:ignore => }

hjnfofvp9ah46dr.delivery.puppetlabs.net (win2012r2) 17:20:08$ cmd.exe /c puppet apply --verbose --detailed-exitcodes C:/cygwin64/tmp/apply_manifest.pp.J1Ipm2
  Notice: Compiled catalog for hjnfofvp9ah46dr.delivery.puppetlabs.net in environment production in 0.20 seconds
  Info: Applying configuration version '1464042015'
  Notice: /Stage[main]/Main/Exec[TestPowershell]/returns: executed successfully
  Notice: Finished catalog run in 3.72 seconds

hjnfofvp9ah46dr.delivery.puppetlabs.net (win2012r2) executed in 24.83 seconds
Exited: 2
    should not error===>                                                                                                                                

[Iristyle]

FWIW, I had rewritten the test a bit differently under vanilla Beaker because I don't think that this test actually demonstrates the catch block is / is not executed, which I think we probably wanted to verify. I think we want positive verification that the code inside the catch was executed.

You can see what I did at https://github.com/puppetlabs/puppetlabs-powershell/pull/88/files#diff-655118f03be5e9bd030d84145ab98dd5R1

This test also is a bit subtle in that it assumes that Write-Error inside the catch, if it were run, would propagate something back to Puppet (which is a separate thing to verify IMHO). I think the rewrite is a bit more explicit as it uses the scripts exit code in an onlyif to determine whether or not to write a file in the command portion.

[ferventcoder]

The issue I had was that if you had a try catch block _NOTHING_ was executed at all in the script. I think I might agree that without some verification that the actual script ran that this is not a fully baked solution.

[Iristyle]

Yeah, and I'm not sure that we're actually verifying that here either @ferventcoder, given the assertion is:

apply_manifest(p1, :expect_changes => true, :future_parser => FUTURE_PARSER)

Beaker docs say:

        # @option opts [Boolean]  :expect_changes (false) This option enables
        #                         detailed exit codes and causes a test failure
        #                         if `puppet --apply` indicates that there were
        #                         no resource changes during its execution.

I don't see mention in the original MODULES-2634 ticket about the Puppet exit status or whether or not it thought it applied resources, in the case where the the PS code did not run...

So I'm not sure the test as written here even does anything to verify whether or not the PS code executed - another reason I'd prefer to move to something very explicit that we can verify on the system (i.e. writing a file like the rewritten test). Then we can clear up any doubts...

[natemccurdy]

In my experience with this bug, I couldn't get anything in the catch block to run. If the try failed, the script would just silently continue on.

There should be a test that the try block works as well as the catch block.

[Iristyle]

An updated PR with new tests is at #113