Allow post/pre hooks to run on upgrade/install/uninstall #1185
Comments
|
Chocolatey does have this concept built-in to it, but it is not consumer based. I think this could be looked at being added as well. Just unsure where this could fall. |
|
I know this is very "edge case" but I too would welcome this feature. It would allow some pre and post processing when installing packages. Some examples:
I'm sure people will come up with many creative uses for it. |
|
I am very interested in this feature. It would be very helpful for my workflow, as I like to archive a copy of programs installers. |
|
https://github.com/Badgerati/Fudge provides the ability to have pre and post hooks , but they run before and after the set of packages, not before/after each one. I am using the post-install hook , loading the Fudgefile, and dynamically calling scriptlets called |
|
https://github.com/Badgerati/Picassio and https://github.com/Badgerati/Picassio2 also provide a way for pre/post hooks. |
|
This feature would be very useful to me. [snip]
"java.home": "{$env:ProgramFiles}\\AdoptOpenJDK\\jdk-14.0.2.12-hotspot",
"java.configuration.runtimes": [
{
"name": "JavaSE-1.8",
"path": "{$env:APPDATA}\\java-1.8.0-openjdk-1.8.0.252-2.b09.redhat.windows.x86_64",
"sources": "{$env:APPDATA}\\java-1.8.0-openjdk-1.8.0.252-2.b09.redhat.windows.x86_64\\src.zip",
"javadoc": "https://docs.oracle.com/javase/8/docs/api",
"default": false
},
{
"name": "JavaSE-14",
"path": "{$env:ProgramFiles}\\AdoptOpenJDK\\jdk-14.0.2.12-hotspot",
"sources": "{$env:ProgramFiles}\\AdoptOpenJDK\\jdk-14.0.2.12-hotspot\\lib\\src.zip",
"javadoc": "https://api.adoptopenjdk.net/",
"default": true
}
],
[snip]However, the paths can break if AdoptOpenJDK is updated. This isn't too big of a hassle, but it would be neat to automate the json update so that a script ran after each JDK update to correct the settings too. |
|
I have a couple of other examples that I have thought of where this would be useful:
|
My thoughts on details of a possible implementation:Create a new package type, the In regards to the types of hooks:
I can't really think of any other categories of hooks that would be useful. Any commands that have hooks possible should have a CLI option to skip hooks. Depending on which categories of hooks are chosen, perhaps CLI options to skip specific types of hooks (eg skip the overall global hooks, but don't skip the install hooks). At least for the individual scripts for install and uninstall, the environment variables should still be set. I'm not %100 what to do for a global hook in regards to the package name+title+version+folder variables, that's something to figure out. The Chocolatey PowerShell functions, and extensions as well should be pre-imported, as in with normal package scripts. Stuff like Re: which edition.
I really don't understand what you mean by "comsumer based". Isn't everyone who uses Chocolatey a consumer? I'm not sure what the alternative to a consumer would be in this context. A developer or vendor maybe? But this is comparatively much less useful to a developer of Chocolatey, as they presumably would have the knowledge and access to create their own packages. While a consumer that just uses Chocolatey would presumably find it much more useful. For example, a developer could make a PR on a package to add a package parameter to remove the desktop shortcut, while a consumer might be stuck asking nicely, in which case a hook that removes desktop icons would come in very useful to the consumer.
Over at chocolatey/chocolatey-licensed-issues#11, you specified "custom user scripts". Does that mean that you are intending the open source edition to have hooks that run globally, while the licensed edition will have support each windows user account having their own hooks? |
Consumer versus Business in this case - the alternative here being organizations using Chocolatey having different needs than individual users.
@TheCakeIsNaOH note this is in "Triaging" label, which means it is not on the backlog and work has not been committed to putting it in. We have tagged the licensed item to put something very similar (if not the same exact thing) into the commercial editions, starting at Pro. |
|
Alright since this is undecided on if it is going into open source choco, if anyone is interested in an implementation of this available now, see my It only does scripts run pre/post the install/modify/uninstall scripts of each individual package, and not scripts that run pre/post of the entire run of choco. For that, two options are choco-upgrade-all-at-startup and choco-upgrade-all-at, both of which have an option to run pre/post run scripts and are created by @bcurran3. |
This adds the code to run Powershell scripts (hook scripts) before and after each type of package automation script runs. The hook scripts can be for all packages, or for a specific package ID. They are put in $env:ChocolateyInstall\hooks, or subfolders thereof. The filename determines when they are run: "<pre|post>-<install|beforemodify|uninstall>-<packageID|all>.ps1"
This adds the ability for choco to install .hook packages that contain hook scripts. Put the .ps1 scripts in the "hook" directory in the package, and make the id of the package end in .hook, and they will get copied to the hook directory
This adds a switch to the install, upgrade and uninstall commands to skip running hook scripts. It adds a configuration option SkipHookScripts.
…cript This allows hooks to run even without a package automation script being present.
…cript This allows hooks to run even without a package automation script being present.
|
After playing around with the It does not do scripts on pack, or global scripts before/after install/uninstall/upgrade, at least not yet. |
This adds the code to run Powershell scripts (hook scripts) before and after each type of package automation script runs. The hook scripts can be for all packages, or for a specific package ID. They are put in $env:ChocolateyInstall\hooks, or subfolders thereof. The filename determines when they are run: "<pre|post>-<install|beforemodify|uninstall>-<packageID|all>.ps1"
This adds the ability for choco to install .hook packages that contain hook scripts. Put the .ps1 scripts in the "hook" directory in the package, and make the id of the package end in .hook, and they will get copied to the hook directory
This adds a switch to the install, upgrade and uninstall commands to skip running hook scripts. It adds a configuration option SkipHookScripts.
…cript This allows hooks to run even without a package automation script being present.
Changing the interface or public methods are breaking changes which we need to wait with implementing before the next major release. As such, this commit adds back the old way of running the powershell host by adding an overload with the original contract for the interface that could possibly be used in other projects that makes use of the Chocolatey.Lib library. This overload has been made obsolete and will just call the new method while setting any hook scripts as empty enumerables.
Add tests that hook scripts execute in scenarios where they're expected to run.
With the upgrade package used in the tests, it currently exits with -1 even though it is successful. Instead of blindly accepting 0 and -1 for all the tests, be explicit about which one we expect so we can catch changes to this exit code.
Add tests that hook scripts execute in scenarios where they're expected to run.
With the upgrade package used in the tests, it currently exits with -1 even though it is successful. Instead of blindly accepting 0 and -1 for all the tests, be explicit about which one we expect so we can catch changes to this exit code.
With the upgrade package used in the tests, it currently exits with -1 even though it is successful. Instead of blindly accepting 0 and -1 for all the tests, be explicit about which one we expect so we can catch changes to this exit code.
(#1185) Add original powershell host run as deprecated method
Add tests that hook scripts execute in scenarios where they're expected to run.
With the upgrade package used in the tests, it currently exits with -1 even though it is successful. Instead of blindly accepting 0 and -1 for all the tests, be explicit about which one we expect so we can catch changes to this exit code.
Add tests that hook scripts execute in scenarios where they're expected to run.
With the upgrade package used in the tests, it currently exits with -1 even though it is successful. Instead of blindly accepting 0 and -1 for all the tests, be explicit about which one we expect so we can catch changes to this exit code.
When passing package parameters into chocolateyScriptRunner.ps1, if there are quotes, PowerShell can get confused. This ensures that we're specifying the new hook arguments and passing nothing if there should be nothing.
When passing package parameters into chocolateyScriptRunner.ps1, if there are quotes, PowerShell can get confused. This ensures that we're specifying the new hook arguments and passing nothing if there should be nothing.
AdmiringWorm
changed the title
|
There is an open documentation PR here: chocolatey/docs#564 It's ready for review, but in draft to prevent merging until the Chocolatey CLI release goes out. |
* release/1.2.0: (374 commits) (maint) Add incoming arguments available in Licensed Extension (chocolatey#798) Add missing pin option in tab completion (chocolatey#2860) Add e2e tests for new PS cmdlet (maint) Fix Chocolatey path in docs generation (chocolatey#2860) Add new PS helper to get maintainer specific paths (chocolatey#2816) Update to latest Chocolatey NuGet.Core (chocolatey#2693) Re-add old resolve or load method (chocolatey#886) Update packages.config install logging (chocolatey#1185) Always pass in hook scripts event if empty Update tests/chocolatey-tests/commands/choco-outdated.Tests.ps1 (chocolatey#2801) Pin Chocolatey packages for outdated tests (chocolatey#886) Use specific strings for configurations (chocolatey#886) Add Pester tests for packages.config (chocolatey#886) Debug log Package configuration (chocolatey#1185) Be explicit with expected exit codes (maint) Pester test directory structure shuffle (chocolatey#1185) Add tests for hook scripts (maint) Minor formatting change (chocolatey#798) Add tests for pinning package on install (chocolatey#2787) Restore Chocolatey snapshot before sxs ...
AdmiringWorm
added
Documentation
Improvement
5 - Released
and removed
Documentation
4 - Done
labels
|
🎉 This issue has been resolved in version 1.2.0 🎉 The release is available on: Your GitReleaseManager bot 📦🚀 |
The idea for this have been taken from pacman (the main package manager for arch linux).
One usage example on how it is used in pacman would be running reflector after pacman-mirrorlist package is updated: https://wiki.archlinux.org/index.php/Reflector#Pacman_Hook
What I request is similiar: have a directory (either configurable or hard coded to
$env:ChocolateyInstall\hookthat stores a bunch of powershell scripts that are meant to be run after/before a package update/install (or after choco have completed the full update/install of all packages).The way I'm thinking this could work is through a naming convention. ie:
(pre|post){pacakge-id}-upgrade/install/uninstall.ps1or(pre|post)global-upgrade/install/uninstall.ps1.The reason I would like to see something like this implemented is because quite a few times I have a need/want to automatically configure some extra configuration for the package(s) that I'm installing (usually user specific configurations) (could range from anything as easy as removing a shortcut, to full configuration of git, virtualbox, smartgit, or even choco. as well as others).
The text was updated successfully, but these errors were encountered: