(#1185) Add hook scripts

[TheCakeIsNaOH]

Description Of Changes

This adds the ability 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 looked for recursively inside $env:ChocolateyInstall\hooks

The filename of the .ps1 file determines when they are run: <pre|post>-<install|beforemodify|uninstall>-<packageID|all>.ps1

The first section is for timing of when the hook script runs. Ore scripts run before the package automation script (e.g. the ChocolateyInstall.ps1), while post scripts are run afterwards. The second section of the filename determines what type of automation script the hook is supposed to run for. The third section either a string of the package ID the hook is to run for, or the keyword all to specify that it should be run for all package IDs.

If a hook needs to be run for more than one of these cases and/or it is complex, the logic can be extracted out to another file or module and dotsourced/imported.

If there are hook script(s) found, they will be run even if there is no package automation script.

The hooks are run in the same context as package automation scripts are, so they have access to the same environment variables as the package scripts do.

It also adds the ability for choco to install .hook packages that contain hook PowerShell scripts, the same in concept as a .template or .extension package.

For packages ending in .hook, any files or directories inside a top level folder called "hook" will be copied to a directory under $env:chocolatey\hooks\ named the same as the package ID with the .hook stripped off the end (e.g remove-shortcuts for a package ID of remove-shortcuts.hook).

During upgrades, this directory will be removed, and updated files will be copied over. During uninstalls, this directory will be removed.

Finally, there is a command line option added to skip hook scripts.

Motivation and Context

See #1185 for most of it

This does not add hooks before pack/push, because validation is planned to be added directly into Chocolatey, https://github.com/chocolatey/choco/issues/602

Hooks that run pre/post everything (e.g. not for each individual package) are not added here, but they could be added in the future more easily with the infrastructure added here.

Testing

Most cases covered by added unit and integration tests.

Manual testing:

• Pack and install the scriptpackage.hook from the integration test context
• Run choco install wget and ensure the pre and post install hooks run
• Uninstall wget
• Run choco install wget --skip-hooks, and ensure that the hooks do not run, but the chocolateyInstall.ps1 does.
• Uninstall wget
• Run choco install wget --skip-powershell, and ensure that neither the hooks nor the chocolateyInstall.ps1 runs.

Change Types Made

• [ ] Bug fix (non-breaking change)
• [x] Feature / Enhancement (non-breaking change)
• [ ] Breaking change (fix or feature that could cause existing functionality to change)

Related Issue

Fixes #1185

Change Checklist

• [x] Requires a change to the documentation
• [ ] Documentation has been updated - will need to add docs, TODO to open an issue on docs repo
• [x] Tests to cover my changes, have been added
• [x] All new and existing tests passed.
• [x] PowerShell v2 compatibility checked.

[coveralls]

Coverage decreased (-0.1%) to 27.592% when pulling d6b9876e8626f131e90d4ea54ad1c7c9119d19f8 on TheCakeIsNaOH:hook-scripts into 6f1afc5e07a34286f7addc43b9af72f7cab03009 on chocolatey:develop.

[TheCakeIsNaOH]

This could use another set of eyes on it to ensure I've not broken anything with regards to the chocolateyScriptRunner.ps1, and to double check that it is PowerShell v2 compatible.

I also could use suggestions for any other automated tests that should be added.

[TheCakeIsNaOH]

but we will also want to ensure any packages that are updated or added here also get added to our internal repository after this is merged.

I'm not quite sure what you mean by this?

If it is the packages added to the integration testing context, those are used only for integration testing, and are build/used only as part of that testing.

[corbob]

but we will also want to ensure any packages that are updated or added here also get added to our internal repository after this is merged.

I'm not quite sure what you mean by this?

If it is the packages added to the integration testing context, those are used only for integration testing, and are build/used only as part of that testing.

What I mean is that currently all of the packages are built automatically in the vagrant environment for any Pester tests that might use them. When we run them within Test Kitchen, they operate against a repository that expects packages to be there. For consistency sake, the package will need to be built by us and pushed to that testing repository in case we ever try to use it from the Pester tests.

[corbob]

Thanks for getting this fixed up @TheCakeIsNaOH!