cChoco
cChoco copied to clipboard
cChocoPackageInstall doesn't check that the package was actually installed
I've noticed a problem with cChocoPackageInstall -- if the package failed to install (due to the source being misconfigured or the version or package name simply not existing) it's not an error. The failure is logged in the verbose output but the DSC configuration silently continues.
This is a pretty nasty surprise; it appears that the DSC you ran completed successfully but in fact some packages were not installed.
Can you provide a scenario to replicate?
Sure! This is all it takes:
Configuration FailingDsc
{
Import-DscResource -ModuleName PSDesiredStateConfiguration
Import-DscResource -ModuleName cChoco
Node localhost
{
cChocoInstaller InstallChocolatey
{
InstallDir = "c:\choco"
}
cChocoPackageInstaller FailingInstaller
{
DependsOn = "[cChocoInstaller]InstallChocolatey"
Name = "This-package-name-has-a-typo"
}
}
}
I'm running this with Start-DscConfiguration -wait FailingDsc
, which exits without errors. Running with -verbose
yields the following log entry:
VERBOSE: [xxxxxxxx]: [[cChocoPackageInstaller]FailingInstaller] Package output
Chocolatey v0.10.3 Installing the following packages: This-package-name-has-a-typo By installing you accept licenses
for the packages. This-package-name-has-a-typo not installed. The package was not found with the source(s) listed. If
you specified a particular version and are receiving this message, it is possible that the package name exists but
the version does not. Version: "" Source(s):
Thanks, once I have some extra time I'll implement something to validate the installer exitcodes and write pester tests :).
Cool, thanks. I was thinking that there's already a function defined "IsPackageInstalled" that I can call at the end of the package installation process, which appears to work.
Does this sound like a good idea? If so, I can submit a PR.
I think it would be better to throw an error if the package install fails. The IsPackageInstalled is intended to get and test the DSC config.
Okay sure. I've created a PR https://github.com/Richiban/cChoco/pull/1 -- I'm not asking you to actually merge it in but just to demonstrate what I meant.
Thanks
Any updates on this, it would be handy for the DSC resource to kick back an error if the package actually failed to install. Right now any depending resources on the package installing successfully will subsequently fail which is fine but would be good to know the root cause of the failure was the install of the package.
This is set to up for grabs for someone to take a look at.
I'm looking to pick this up. Does anyone know why it's using Invoke-Expression
for all of the choco
calls? Error handling is a bit more challenging when using that.
$packageInstallOuput, $exitCode = Invoke-Expression -Command "(choco install $pName $chocoinstallparams), $?"
vs
$packageInstallOuput = choco install $pName @chocoinstallparams
$exitCode = $?
On second thought, this is probably for the best, I've run into a few Chocolatey packages that can't be installed by the System user and this makes it easier to enhance with a Credential
parameter for those of us stuck on PS 4.0 (PR likely coming for that as well)
@elovelan if you have specific packages you can point to that have issues, that would be most helpful.
@ferventcoder, is your question about packages that will not install under the System account or about packages that fail?
In terms of failure, this is really more about general error handling than just packages that fail to install.
The .NET framework and visual studio isolated shells are examples of packages that will not install under the System account. I can't remember the exact reasons, but the error is from the MSI, it's not a Chocolatey-specific issue. The work-around is to install using the built-in Package
resource with the Credential
option.
The work-around is to install using the built-in
Package resource
with the Credential option.
@elovelan does cChoco not support the Credential option? I was under the impression that DSC supported Credentials across the board?
is your question about packages that will not install under the System account or about packages that fail?
@elovelan I was specifically speaking of installers that had issues under the system account (not necessarily packages)
does cChoco not support the Credential option? I was under the impression that DSC supported Credentials across the board?
This is supported as of PS 5.0, unfortunately not everyone is able to move to it in a timely fashion :smile:
Double quotes like that won't work because $? will be evaluated to whatever the variable contains, sticking with Invoke-Expression, you'd need something like this:
$param = '--localonly'
$exp = "choco list $param"
$exp += ';$?'
$e = Invoke-Expression -Command $exp
$p = $e | select -skip 1 -last $e.Length | Out-String
if ($e | select -last 1)
{
Write-Host "Sweet as!"
Write-Host "Output was:`n $p"
}
else
{
Write-Host "Shucks it broke!"
Write-Host "Output was:`n $p"
}
Note the single quotes in line 3 above. If you change 'choco list' to 'choco lust' to simulate an error, you get:
Shucks it broke!
Output was:
Chocolatey v0.10.6
Could not find a command registered that meets 'lust'.
Try choco -? for command reference/help.
There is now a pull request for this issue. #103
Any updates on this?
- 1 This is quite an important fix for us.
+1 - Could really use this fixed as well - if there anything in particular it's waiting on? Or just the next release?
I'm affected by this as well. I have an internal 7zip package that I tried to install. Since I'm new to DSC I wanted to see what would happen if intentionally typed the package named 7zip incorrectly. The Start-DscConfiguration completed without error. However, Test-DscConfiguration returns [cChocoPackageInstaller]Install7zip is not in the desired state. Additionally, I have an error in the chocolatey.log that states that the 72zip
package can't be found in my source list - as expected.
This is waiting on PR changes - https://github.com/chocolatey/cChoco/pull/103
Any updates on this? This does create some nasty surprises on failing installs