Repository navigation
Add ability to run arbitrary hooks pre/post version bump #292
Description
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:
- before changelog
- after changelog and before commit and tag
- 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.
Activity
woile commentedon Nov 4, 2020
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 commentedon Nov 4, 2020
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
In case of the "pre-bump" hook I think these variables would be useful in the environment of the executed script/command:
woile commentedon Nov 11, 2020
Hey @janw I'm interested. I'd like to see it.
Regards!
janw commentedon Nov 13, 2020
Awesome, I'll make it presentable early next week and get back to you! 💪
skoef commentedon Dec 20, 2022
@janw did you ever find the time to make that PR? I'd love similar functionality as well!
skoef commentedon Dec 21, 2022
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 commentedon Dec 21, 2022
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.
feat(bump): added support for running arbitrary hooks during bump
feat(bump): added support for running arbitrary hooks during bump
feat(bump): added support for running arbitrary hooks during bump
feat(bump): added support for running arbitrary hooks during bump
feat(bump): added support for running arbitrary hooks during bump
feat(bump): added support for running arbitrary hooks during bump
feat(bump): added support for running arbitrary hooks during bump
feat(bump): added support for running arbitrary hooks during bump