Closed mwallner closed 2 months ago
My view on hook packages is that they will only execute when the installation is successful. They are a post-package-action-execution that really only makes sense in that context.
I can see the concept of error capturing that was mentioned over on the hook issue that you linked to. However, that would require further reworking in this area both in terms of code and in terms of the hook scripts themselves to 'only do this when successfully' and 'only do this in failure'. Or perhaps have separate scripts for success (the existing ones) and failure (new ones).
While I agree this makes sense from a naming-perspective (post-install = "do this after installation finished" ..) it's a bit harder to utilize hook-packages for building a custom logging-system that's supposed to really be in-sync with the local package index.
it's a bit harder to utilize hook-packages for building a custom logging-system that's supposed to really be in-sync with the local package index.
Can you elaborate on that for more context?
one could create a "org-custom-logging.hook" package with something like this:
(think about Invoke-SendToMyOrgElastic
as some generic CMDLet that'll take some PSObject, convert it to json and throw it against an ElasticSearch REST endpoint)
pre-install
@{
ComputerName = $env:COMPUTERNAME
UserName = $env:USERNAME
State = 'PreInstall'
ChocoPackage = $env:ChocolateyPackageName
ChocoPackageVersion = $env:ChocolateyPackageVersion
} | Invoke-SendToMyOrgElastic
post-install
@{
ComputerName = $env:COMPUTERNAME
UserName = $env:USERNAME
State = 'PostInstall'
ChocoPackage = $env:ChocolateyPackageName
ChocoPackageVersion = $env:ChocolateyPackageVersion
} | Invoke-SendToMyOrgElastic
This way, one would know when a package installation began and when it was finished, but you'd have to deduce if the install script was successful by checking if both events (State.PreInstall
as well as State.PostInstall
) are present.
=> that could be way more elegant if there was a $env:ChocolateyPackageInstallScriptSuccessState
(or similar)
And yes, I'm aware that if you're looking for a complete inventory and complete management suite, there's CCM 😉
The intention of hook scripts was to run only when successful. I understand the use case that you have, but the functionality was never intended to support that.
I would see this as intended behaviour and not a bug. It could be an improvement to how hook scripts operate and be added by the community. It's not something I see us working on any time soon.
My intention would be to close this @mwallner but happy for a feature to be opened for it to be added.
The intention of hook scripts was to run only when successful.
That is the way I intended them to work, as then any hook which makes changes based on a successful package script execution should not have to explicitly check that the package script worked.
I had not considered this use case of remote logging, but that does seem to align with an organizational only use case.
Heya, thanks for the insights, I'm happy closing this as "working as designed". (I'm kind of used to being the guy with the weird edge cases anyway :stuck_out_tongue_winking_eye:)
Kudos @TheCakeIsNaOH - didn't realize you've been involved in the bring-up of this amazing feature :smiley: :clap:
Checklist
What You Are Seeing?
When a package installation fails no further post-install "package hook" is executed, (neither global nor package-specific).
This has (kind of) been discussed here before - looks like it's been lost in time.
What is Expected?
post-install hooks should fire even if the installation fails .
How Did You Get This To Happen?
System Details
Installed Packages
Output Log
Additional Context
No response