choco hook package - post-install trigger does not fire when package installation fails about choco

[mwallner]

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 😉

[pauby]

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).

[mwallner]

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.

[pauby]

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?

[pauby]

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.

[TheCakeIsNaOH]

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.

[mwallner]

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 😜)

Kudos @TheCakeIsNaOH - didn't realize you've been involved in the bring-up of this amazing feature 😃 👏