New feat: Retry logic & exit with winget Exitcode#895
New feat: Retry logic & exit with winget Exitcode#895FaserF wants to merge 18 commits intoRomanitho:developfrom FaserF:add-retryLogic-Exitcode
Conversation
|
Install OK (haven't tested what happens if failed): Uninstall with $Appargs OK, but when uninstalling with or without $Appargs this comes in the terminal: 19:07:44 - Start Azul.Zulu.11.JRE processing... |
|
Test with fail (just open a termin without admin rights, try to install a program that needs admin rights and cancel the admin prompt: With the -DisableRetry Param: Uninstall: With -DisableRetry Param: |
I have now fixed it in the latest commit, I dont get it where it gets called with a wrong color param, but we now always use white as a fallback. |
|
Confirmed behavior with another MSI installation ongoing: Uninstall: After that Retry 1 was enough (the other installation was completed) to complete the install/uninstall |
But I notice that the exit codes from the winget run is not the actual exit code from in this case the MSI installation (1618) making your test for 3010, 1641, etc impossible to catch. |
|
But, you can translate them first: |
|
EDIT: only 1 Function now with helper functions inside:
I got an idea. Feel free to incorporate it if you think it's a good one (think I got the most right).
Include it as the other ones and call Or do your translate.
I've included the parsing for |
Last one 😉 Then it can run for SYSTEM/user without more tinkering. |
| $Log | Write-host -ForegroundColor $LogColor | ||
| if ($LogColor -notin @("Black", "DarkBlue", "DarkGreen", "DarkCyan", "DarkRed", "DarkMagenta", "DarkYellow", "Gray", "DarkGray", "Blue", "Green", "Cyan", "Red", "Magenta", "Yellow", "White")) { | ||
| $LogColor = "White" | ||
| } |
There was a problem hiding this comment.
for me colors don't make sense anymore for logs.
There was a problem hiding this comment.
I have only added this, since some logging commands failed due to missing or wrong color parameters. For this feature here its not specifilcy needed, but I would leave it in there to reduce potential errors
Thanks for finding that, really good. I will try to do some more research if we maybe can directly access the installer return code (not the winget return code). If there is no way, your idea looks good. |
Nah, don't bother with that extra function! |
|
What do you @KnifMelti & @Romanitho think about this: When we add support for that with WAU, it would be easy to retrieve the installer return code: microsoft/winget-cli#5375 |
|
From my point of view, we need to make a choice: either we stick with Winget and keep using our PowerShell wrapper, or we move to the official module — but that would require PowerShell 7 as a prerequisite on all devices. Maintaining both approaches could overload the project, which is already somewhat messy and definitely needs a cleanup to reorganize things, streamline the whole process, and so on. |
|
It may also be worth looking at the approaches taken in the PSADTv4 WinGet Module to see what the solutions are there. |
Close but no cigar @KnifMelti. PSAppDeployToolkit.WinGet is not performing any ForEach loops, PDT and its winget derivative are focused on carrying out a single installation after all. That project includes full return codes table from winget repo: enum ADTWinGetExitCode
{
INTERNAL_ERROR = -1978335231
# (...) etc.. etc..
}Installation can pass the exit code to parent process: $wingetResult = $null
try
{
try
{
# Perform the required operation.
$wingetResult = Invoke-ADTWinGetDeploymentOperation -Action Install @PSBoundParameters
}
catch
{
# Re-writing the ErrorRecord with Write-Error ensures the correct PositionMessage is used.
Write-Error -ErrorRecord $_
}
# Throw if the result has an ErrorRecord.
if ($wingetResult.ExtendedErrorCode)
{
Write-Error -ErrorRecord $wingetResult.ExtendedErrorCode
}
}
catch
{
# Process the caught error, log it and throw depending on the specified ErrorAction.
Invoke-ADTFunctionErrorHandler -Cmdlet $PSCmdlet -SessionState $ExecutionContext.SessionState -ErrorRecord $_ -LogMessage "Failed to install the specified WinGet package."
}
# If we have a result and are passing through, return it.
if ($wingetResult -and $PassThru)
{
return $wingetResult
}If something goes wrong, then the results are processed using |
5 participants
Proposed Changes
Sometimes a installation in our company environment fails due to "another installation is already in progress".
This PR adds a simple retry logic, where an installation will be tried three times per default. This can be disabled with the param
-DisableRetry.Also Winget-Install now exits the script not always with 0 (success), instead the winget installation return code will be used to exit this script. This helps with handling Error Codes through SCCM & Intune.
Related Issues