-
Notifications
You must be signed in to change notification settings - Fork 900
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Run a script before uninstall/upgrade (chocolateyBeforeModify.ps1) to allow for things like services to shutdown #268
Comments
This is for you @darrelmiller |
Awesome. Will try it out soon! |
This is only the ticket. A placeholder for the work. ;) |
Hehe. I guess I need to read more closely. Will wait with baited breath! |
Run chocolateyBeforeRemove.ps1 when you want to shut down a service before upgrade doesn't sound logical to me, I would expect a chocolateyBeforeUpgrade.ps1. |
Before remove to signify it is run in upgrades and uninstalls - no reason to write tge same logic twice in your automation scripts. |
Might need a better name but it needs to signify that by the name that it is done prior to the upgrade/uninstall action and that it is not a script meant for handling the upgrade, only preparing for an upgrade or uninstall. |
Any reason why you propose 1 script for both upgrade and uninstall? And if you do an uninstall what can be done extra in chocolateyBeforeUpgrade.ps1 what cannot be done in chocolateyUninstall.ps1? |
Think of it like this - if you have a service running and you need to shut it down, you need to shut it down before ANY changes can be made. So the uninstall script is still going to run on uninstalls, we are not replacing that. Imagine for a second if you needed to shut down a service before upgrade or uninstall, and we only had a beforeUpgrade.ps1. So now you need to include the exact same logic TWICE in your scripts, once for upgrades and once for uninstalls. Now every time you need to adjust that logic, you have to remember to adjust it in both places. That would not be maintainable and not much fun. (Yes, I know you could dot source a function from another script, but most scripts self-contain all logic). |
Ok I get it. Would there be an option to know if you're running an upgrade or uninstall if there's things you only want to do during an upgrade? (I don't have a particular use-case at this moment, but I can imagine that you need to do something special only on upgrade) |
Right now, the thought wasn't there, but it could easily be passed the action that was about to occur. In some MSIs, folks want to uninstall before upgrading (mostly because some minor versions of MSIs don't always upgrade at all). |
This action will trigger the execution of chocolateyBeforeModify.ps1 if that script is present in the package.
…thod. If not null, this action should be triggered in an update scenario but in the forseeable future the action will only be used by the NugetService (from where it will be used to trigger execution of the chocolateyBeforeModify script described in chocolateyGH-268).
…kageService This method is passed into the ISourceRunner instance's upgrade_run as the beforeUpgradeAction. Only the NugetService currently uses it to trigger execution of the pre-modification script.
…ecution. While there appeared to be verification in the noop scenario, there did not appear to be any verification in the regular case. These spec items verify that the encapsulated package script was run by examining the script output.
…ages. If we are going to verify script execution, it needs to be included in the test packages.
…ackage. There were a several places with functionally identical code to locate the installation folder for a package. When the new pre-modification script gets added the same functionality will be needed again. Refactored into a method to eliminate additional duplicate.
…rios. These scenarios verify that chocolateyBeforeModify.ps1 is executed on the correct package version when appropriate.
This action will trigger the execution of chocolateyBeforeModify.ps1 if that script is present in the package.
…thod. If not null, this action should be triggered in an update scenario but in the forseeable future the action will only be used by the NugetService (from where it will be used to trigger execution of the chocolateyBeforeModify script described in chocolateyGH-268).
…kageService This method is passed into the ISourceRunner instance's upgrade_run as the beforeUpgradeAction. Only the NugetService currently uses it to trigger execution of the pre-modification script.
Ensure the folder is renamed prior to running before modify for the package.
- Adding back in chocolateyGH-560 - loading modules from known location (90d53ee) - Adding back in chocolateyGH-542 - not running templated scripts (d5f09bf)
A failure in the before modify script should report the error but not do anything to stop the script from failing.
* pr531-modify: (chocolateyGH-268)(specs) BeforeModify failure is ignored (maint) remove comment (chocolateyGH-268) Revert removed fixes (chocolateyGH-268) Rename Legacy Prior to Before Modify (maint) formatting (chocolateyGH-268) Use MockLogger.contains_message in verification expressions. (chocolateyGH-268) Trigger beforeUpgradeAction from the NugetService. (chocolateyGH-268) Add before-package-upgrade method to ChocolateyPackageService (chocolateyGH-268) Add optional beforeUpgradeAction to upgrade_run method. (chocolateyGH-268) Add a before_modify action to the PowershellService (chocolateyGH-268)(spec) Added "before modify" integration test scenarios. (chocolateyGH-268) Extract method to provide folder information for package. (chocolateyGH-268) Add chocolateyBeforeModify.ps1 script to test packages. (chocolateyGH-268)(spec) Add scenarios verifying powershell script execution.
* stable: (chocolateyGH-268)(specs) BeforeModify failure is ignored (maint) remove comment (chocolateyGH-268) Revert removed fixes (chocolateyGH-268) Rename Legacy Prior to Before Modify (maint) formatting (chocolateyGH-268) Use MockLogger.contains_message in verification expressions. (chocolateyGH-268) Trigger beforeUpgradeAction from the NugetService. (chocolateyGH-268) Add before-package-upgrade method to ChocolateyPackageService (chocolateyGH-268) Add optional beforeUpgradeAction to upgrade_run method. (chocolateyGH-268) Add a before_modify action to the PowershellService (chocolateyGH-268)(spec) Added "before modify" integration test scenarios. (chocolateyGH-268) Extract method to provide folder information for package. (chocolateyGH-268) Add chocolateyBeforeModify.ps1 script to test packages. (chocolateyGH-268)(spec) Add scenarios verifying powershell script execution.
With the move to finding the script in a singular function, the old code no longer is used. Remove it.
* stable: (chocolateyGH-268) Remove Unused Code (chocolateyGH-268) Add BeforeModify to install template (maint) solution folders for nuspecs / top level (maint) catch pack catastrophic errors (chocolateyGH-586) Ignore invalid options/switches by default (specs) update scenarios (chocolateyGH-596) Allow failure on invalid license (chocolateyGH-571) Arg parsing error should be warning (chocolateyGH-680) Switch to .NET Client Profile
Really happy to see this feature. I have big plans for this :-) |
Do not fail if it fails though.
Current proposed name:
chocolateyBeforeRemove.ps1
Migrated the evolution of the ideas from chocolatey-archive/chocolatey#291
tl;dr - There is a before modify script. It runs in addition to your chocolateyInstall.ps1 during upgrades and in addition to your chocolateyUninstall.ps1 during uninstalls. See https://github.com/chocolatey/choco/wiki/CreatePackages#during-which-scenarios-will-my-custom-scripts-be-triggered
The text was updated successfully, but these errors were encountered: