search

chocolatey / chocolatey-ansible

The Chocolatey module collection for Ansible
GNU General Public License v3.0
47 stars 29 forks source link

Win_chocolatey task crashes if PATH contains multiple choco.exe on the target machine #147

Open vector-jnajjar opened 2 months ago

vector-jnajjar commented 2 months ago

Checklist

What You Are Seeing?

When I try to use win_chocolatey to install any package on a target machine that has two chocolatey installations in the path, I get a powershell syntax error:

System.Management.Automation.ParameterBindingArgumentTransformationException: Cannot process argument transformation on parameter 'ChocoCommand'. Cannot convert the "System.Object[]" value of type "System.Object[]" to type "System .Management.Automation.CommandInfo"

This means that a CommandInfo is expected but a List is received.

What is Expected?

win_chocolatey should not crash

How Did You Get This To Happen?

I ran ansible with a playbook containing win_chocolatey

System Details

Installed Packages

N/A

Output Log

The full traceback is:
Cannot process argument transformation on parameter 'ChocoCommand'. Cannot convert the "System.Object[]" value of type "System.Object[]" to type "System.Management.Automation.CommandInfo".
At line:139 char:17
+ $chocoCommand = Install-Chocolatey @installParams
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidData: (:) [Install-Chocolatey], ParameterBindingArgumentTransformationException
    + FullyQualifiedErrorId : ParameterArgumentTransformationError,Install-Chocolatey

ScriptStackTrace:
at Install-Chocolatey, <No file>: line 1229
at <ScriptBlock>, <No file>: line 139

System.Management.Automation.ParameterBindingArgumentTransformationException: Cannot process argument transformation on parameter 'ChocoCommand'. Cannot convert the "System.Object[]" value of type "System.Object[]" to type "System
.Management.Automation.CommandInfo". ---> System.Management.Automation.ArgumentTransformationMetadataException: Cannot convert the "System.Object[]" value of type "System.Object[]" to type "System.Management.Automation.CommandInfo". ---> System.Management.Automation.PSInvalidCastException: Cannot convert the "System.Object[]" value of type "System.Object[]" to type "System.Management.Automation.CommandInfo".
   at System.Management.Automation.LanguagePrimitives.ThrowInvalidCastException(Object valueToConvert, Type resultType)
   at System.Management.Automation.LanguagePrimitives.ConvertNoConversion(Object valueToConvert, Type resultType, Boolean recurse, PSObject originalValueToConvert, IFormatProvider formatProvider, TypeTable backupTable)
   at System.Management.Automation.LanguagePrimitives.ConversionData`1.Invoke(Object valueToConvert, Type resultType, Boolean recurse, PSObject originalValueToConvert, IFormatProvider formatProvider, TypeTable backupTable)        
   at System.Management.Automation.LanguagePrimitives.ConvertTo(Object valueToConvert, Type resultType, Boolean recursion, IFormatProvider formatProvider, TypeTable backupTypeTable)
   at System.Management.Automation.ArgumentTypeConverterAttribute.Transform(EngineIntrinsics engineIntrinsics, Object inputData, Boolean bindingParameters, Boolean bindingScriptCmdlet)
   --- End of inner exception stack trace ---
   at System.Management.Automation.ArgumentTypeConverterAttribute.Transform(EngineIntrinsics engineIntrinsics, Object inputData, Boolean bindingParameters, Boolean bindingScriptCmdlet)
   at System.Management.Automation.ParameterBinderBase.BindParameter(CommandParameterInternal parameter, CompiledCommandParameter parameterMetadata, ParameterBindingFlags flags)
   --- End of inner exception stack trace ---
   at System.Management.Automation.ExceptionHandlingOps.CheckActionPreference(FunctionContext funcContext, Exception exception)
   at System.Management.Automation.Interpreter.ActionCallInstruction`2.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.Interpreter.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.LightLambda.RunVoid1[T0](T0 arg0)
   at System.Management.Automation.PSScriptCmdlet.RunClause(Action`1 clause, Object dollarUnderbar, Object inputToProcess)
   at System.Management.Automation.PSScriptCmdlet.DoEndProcessing()
   at System.Management.Automation.CommandProcessorBase.Complete()
fatal: [vistrcfgcis011.vi.vector.int]: FAILED! => {
    "changed": false,
    "msg": "Unhandled exception while executing module: Cannot process argument transformation on parameter 'ChocoCommand'. Cannot convert the \"System.Object[]\" value of type \"System.Object[]\" to type \"System.Management.Automation.CommandInfo\"."
}

Additional Context

I have a fix

pauby commented 2 months ago

This feels like trying to fix the symptom, rather than the problem. Chocolatey CLI installation path should not be on the PATH twice and in all my time working with it, I've never seen it on there, multiple times.

Has there been troubleshooting on why it's ending up on the PATH twice?

vector-jnajjar commented 2 months ago

Hi, it is in the PATH twice because there are two separate installations that govern two sets of installed programs. It is not my idea, but the person responsible told me that there are reasons. Nevertheless, I think ansible should not crash, and therefore the capability of Get-Command to return a list should be accounted for. I think that behaving the same way as typing the choco.exe command in a Powershell is also what the user expects. This motivated me to propose this fix.

pauby commented 2 months ago

it is in the PATH twice because there are two separate installations that govern two sets of installed programs.

Is that two separate installations of Chocolatey CLI? If that is the case that is not supported.

It is not my idea, but the person responsible told me that there are reasons.

I'd be interested to know what those reasons are as I cannot imagine any situation where you would need two separate installations of Chocolatey CLI.

If my understanding above is correct, the environment you are running in is going to lead to problems of all sorts and is not supported. I'm interested to understand the reasons for having multiple installation to see if we can get you to a know good supported state.

vector-jnajjar commented 2 months ago

Well, I see two points here:

  1. Should win_chocolatey crash if it does not need to?
  2. The setup is in corporate context, there is a mechanism that allows Jenkinsfiles to allow to install software via choco, that is needed for the Jenkins-Job. These are kept separate from the software that is installed by our IT. So the second "installation" of choco has a completely different purpose and configuration. It is also not what I would use to install packages via ansible. There is no need to support multiple choco installations, or make it configurable.

All in all, I think improving the stability of win_chocolatey is only beneficial.

pauby commented 2 months ago

I think you misunderstand or I've not been clear.

I am not suggesting we don't implement the fix. I'm suggesting that the problem you have put your environment into is:

  1. Not supported.
  2. Not what the playbook is designed to handle.
  3. Is problematic and will bite you at some point in the future somewhere else.

The playbook is not designed to support multiple Chocolatey CLI installations, so that is why you are seeing the issue. It is not desirable, but it is expected behaviour.

Thank you for the PR. To set expectations, we don't have any plans to release a new version of the collection in the near future. But it is something we will get released.

vector-jnajjar commented 2 months ago

@pauby Thanks a lot! I am glad this will be released. As for our setup, I will look into it some more, thanks for your suggestions.