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

[mwallner]

Checklist

• I confirm there are no unresolved issues reported on the Chocolatey Status page.
• I have verified this is the correct repository for opening this issue.
• I have verified no other issues exist related to my problem.
• I have verified this is not an issue for a specific package.
• I have verified this issue is not security related.
• I confirm I am using official, and not unofficial, or modified, Chocolatey products.

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?

• Create a global hook package with pre / post - installation hooks
• choco install
• post-hook never gets run

System Details

• Operating System: Windows 10 LTSC
• Windows PowerShell version: 5
• Chocolatey CLI Version: 2.2.2
• Terminal/Emulator: cmd/conhost

Installed Packages

-

Output Log

-

Additional Context

No response

[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?

[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]

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 😃 👏