Add ability to run arbitrary hooks pre/post version bump

[janw]

Description

To use the currently available hook facilities, it is necessary to create a custom cz_ adapter class to use hooks during the version bump / changelog generation. I'd like to be able to run arbitrary hooks (i.e. a shell script or other external executable) from a simple configuration file section. In my specific use-case I'd like for the hooks to be run after the changelog generation and before the version bump in case of cz bump --changelog (see also #290), but I can imaging the following hook locations to be useful:

1. before changelog
2. after changelog and before commit and tag
3. after tag

Possible Solution

Implement hook facilities at the aforementioned locations. They should be configurable via the configuration file for example as follows, allowing for multiple commands to be run at a given location

[[tool.commitizen.hook_begin]]
command = "./update-something.sh"

[[tool.commitizen.hook_begin]]
command = "./do-another-thing.sh"

[[tool.commitizen.hook_before_commit]]
command = "./build-something-based-on-changelog.sh"

[tool.commitizen.hook_end]
command = "./push-artifacts.py"

Given commands should run with useful execution context, such as current and future version as arguments and/or environment variables.

---

I'd be happy to implement this as well. Cheers.

[woile]

This is actually super interesting.
I wonder if it doesn't introduce any security issues.
Each of those functions would be called with the arguments, right? Like if you execute the hook after the changelog generation, your script should receive the changelog generated.

I actually think that these hooks would be great candidates for plugins, as proposed in #287

[janw]

I guess you're right, it does have some security implications when running arbitrary code is allowed. But I'd argue that the commands that are run are inherently documented in the config file (i.e. it's clear for every commit what scripts are going to be run) and that somewhat alleviates these implications.

In a PoC that I'm preparing (just for myself, even if you'd decide not to merge it), I went for providing the arguments via environment variables, as it allows for more context to be passed to the script. Also I reduced the lists to a more simple syntax

[tool.commitizen]
# ...
hooks_pre_changelog = [
  "./update-something.sh",
  "./do-another-thing.sh"
]
hooks_pre_bump = [
  "./build-something-based-on-changelog.sh"
]
hooks_post_bump = [
  "./push-artifacts.py"
]

In case of the "pre-bump" hook I think these variables would be useful in the environment of the executed script/command:

CZ_BUMP_IS_INITIAL= 
CZ_BUMP_CURRENT_VERSION= 
CZ_BUMP_CURRENT_TAG_VERSION= 
CZ_BUMP_NEW_VERSION= 
CZ_BUMP_NEW_TAG_VERSION= 
CZ_BUMP_MESSAGE= 
CZ_BUMP_INCREMENT= 
CZ_BUMP_CHANGELOG_FILE_NAME= 

[woile]

Hey @janw I'm interested. I'd like to see it.
Regards!

[janw]

Awesome, I'll make it presentable early next week and get back to you! 💪

[skoef]

@janw did you ever find the time to make that PR? I'd love similar functionality as well!

[skoef]

I see that you did make a branch for your work, @woile would this qualify to be merged? If so, I'd be happy to backport this to the current master of commitizen and send in a PR.

[janw]

Hey, apologies @skoef, I ended up not finishing up the work after some personal business at the time, and the team ended up not needing the feature anymore after some time.

But yeah, if somebody wants to implement this, feel free to re-use / claim this commit on my fork that has the initial work I did for it.