Exit with the same exit code as the software being installed #512
Comments
|
I like it - some questions. Typically choco installs multiple packages at a time, whether through dependencies, packages.config, ir specifying multiple on the command line. When one of those fails, it is easy to say the exit code could be the same for the one that failed. What should we do when multiple packages fail? |
|
I think the easiest implementation would be for choco to just return the exit code of the last package that failed. If/when someone wants to know the exit code of previous package failures, we may want to add a command line parameter that instructs choco to stop immediately when any package fails. Thank you. |
|
It still feels like there is an inconsistency, which can lead to weird expectations. For instance, tell me why you want this feature in the first place? |
|
@icnocop we do have a stop immediately flag I believe. If not, we may want to add one. |
|
I want this feature so that I could handle the exit codes programmatically myself. For example, when testing installing a chocolatey package on a VMware virtual machine, there may be a couple of reboots required before the package has successfully been installed. I expect to programmatically call choco.exe to install one (or more) chocolatey package(s) and wait for it to exit. If choco.exe returns exit code -2147185721, which means a pending restart is required: If choco.exe returns exit code 3010, which means a reboot is required: If choco.exe returns exit code 0, which means that all packages have successfully been installed, then I would take a virtual machine snapshot. I'm only currently testing choco.exe with one chocolatey package at a time, but I've also included the ability to use this feature with multiple packages in the above scenario. Thank you. |
|
@icnocop I'm sure you've heard of boxstarter? |
|
@icnocop would it be more beneficial for choco to return a special exit code for reboot required? Or do you see other use cases? The reason I ask is that choco is meant as a unification point - instead of having to track two separate (or more) exit codes, you could track one as choco would know when an install requires a reboot and pass that single exit code to you. |
|
And for anything it didn't recognize, it could pass back that exit code instead |
|
Yes, I tried to use boxstarter. See the discussion here: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!topic/boxstarter/Xf0J6eWYI7s boxstarter.exe doesn't return with an exit code of the package(s) being installed either. I'm thinking if/maybe when choco has support for this feature, then boxstarter can also be updated to support it, but I believe choco should be first because boxstarter utilizes choco in the first place. I don't think choco should translate the exit code because different packages may have different exit codes. |
|
I just meant because boxstarter can handle the reboots for you. |
3010 - always always always a reboot exit code for an MSI package. I'm not sure if you are aware of this or not, but Chocolatey is somewhat smart about the different installers and next year once it is implemented, choco will be able to handle quite a bit more automatically if one just tells Choco what type of installer it is. |
|
Yes, I noticed that Install-ChocolateyPackage already accepts an "installerType" parameter. I just simply would like to get the exit code of the package after running Thank you. |
|
@icnocop I understand - I'm simply seeing if there is another avenue we are not thinking about here. |
|
I know it's hard to see as it's easy to visualize what you already have to deal with and almost impossible to visualize something intangible that may be a better solution. :) |
|
Ok, thank you! 😃 |
|
Let's say we do the simple route for now - per package return |
If a package is a warning or an error, display that exit code result next to the package name.
When running native installers, allow choco to exit with the same exit code as the installer. Additionally, detect valid exit codes and do not error when receiving those exit codes. Pass the exit code to the package so that result can be passed back.
* stable: (maint) rename Get-FileName to Get-WebFileName (maint) Log host version as well. (GH-512) Exit with same code as installer (GH-707) Exit with specific exit codes (GH-649) Error if executable is text file (GH-709) Get Exit code from PowerShell Host (GH-512) Display exit code for packages (GH-710) prompt with timeout on some commands (maint) better error handling
|
@ferventcoder, salted chocolate is surprisingly delicious. |
|
Somehow I missed this issue. I'll work on making sure ChocolateyGUI recognizes and alerts to non-zero and reboot codes. |
|
@RichiCoder1 sorry man! Totally forgot to mention this to you :/ |
|
It's okay because it's something you will need as you upgrade to 0.9.10 |
|
Nah, you mentioned me here #512 (comment) hence why I noticed this now :) |
Starting with 33b6285, which was released as part of GH-512 in 0.9.10, we started checking `$LASTEXITCODE` in addition to the script command success. This meant it offered the ability to capture when a script exited with `exit 1` and handle that accordingly. However that was not a recommended scenario for returning errors from scripts. Checking `$LastExitCode` checks the last executable's exit code when the script specifically does not call `Exit`. This can lead to very perplexing failures, such as running a successful xcopy that exits with 2 and seeing package failures without understanding why. Since it is not typically recommended to call `Exit` to return a value from PowerShell because of issues with different hosts, it's less of a concern to only look at explicit failures.
|
Attempting to upgrade the chocolatey package called DraftSight https://chocolatey.org/packages/draftsight Ansible win_chocolatey throws a 1603 error Microsoft says, "Windows Installer is attempting to install an app that is already installed on your PC" Upgrading with "cup all" works fine. Putting this here as it looks like 1603 might be another one of these exit codes? |
|
@basictheprogram 1603 is a generic error, but rest assured that it is not one of the known good exit codes. Each package can implement their own valid exit codes so if there is a particular exit code an app passes that indicates success that is not one of the defailts, they can passs those in through the package itself. |
|
Why doesn't "cup all" or "choco upgrade draftsight" not error? Only when I try to upgrade the package via win_chocolatey does it error. Looking at the win_chocolatey code it invokes choco so I'm guessing cup and choco.exe are less picky about exit codes? |
|
@basictheprogram looks like |
|
Not a ton of info in that response sorry. WinRM may behave differently. Ensure you are on the most up to date version of the Chocolatey module and a very recent version of Ansible as well. |
|
I run devel branch from Ansible git repository, updated daily.
…--
Bob Tanner <[email protected]> | Phone : 952-943-8700
http://www.real-time.com, Linux, OSX, VMware, Windows | Fax : 952-943-8500
Key fingerprint = 9906 320A 8BB6 64AD 96A7 7785 CBFB 10BF 568B F98C
|
I'd like to request allowing choco.exe to return with the same exit code as the package it's installing.
In this way, the calling process can choose how to handle a specific exit code (ex. a reboot).
This request has stemmed from two discussions:
mwrock/Chocolatey-Packages#30
https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!topic/boxstarter/Xf0J6eWYI7s
I'm not sure if this should be the default behavior because it may cause unexpected behavior with boxstarter for example, unless boxstarter is also updated accordingly.
Thank you.
Related to #712, #707, and #709.
The text was updated successfully, but these errors were encountered: