Add pre/post bump plugins

[Clockwork-Muse]

Description

Currently, the ability to customize pre/post bump behavior is limited to script hooks. While these hooks are able to run arbitrary commands and scripts, their integration is limited, and they are not called if the --dry-run flag is passed.

I'd like to be able to write pre/post bump hooks in python and have them run in all cases, with some explicit api setup that also presents dry run/actual run information. One use case is a hook that modifies CI environments with variables presenting the current/next version (Eg, an equivalent of Semantic Release's semantic-release-ado plugin).

Possible Solution

It's possible to modify the current hook system to provide this information as an environment variable, but this would likely cause chaos unless the configuration file was changed as well to reflect this.

I would prefer some base class that could be implemented and then automatically loaded, as is the case for the existing (non-hook) plugins.
Providing a more general plugin system, supporting more events (As semantic-release does) may provide future additional benefits (although is also more complex).

Additional context

No response

Additional context

No response

[woile]

Hi, in my experience, the script hooks have been a problem, and the user I helped solved the problem in a different way in the end.

Would something like this helped instead?
commitizen-tools/commitizen-action#76 (comment)

Then you would only need the current version, which you can retrieve with

cz version -p

[Clockwork-Muse]

Unfortunately I'm on Azure devops, so the action isn't available to me.
I've already written equivalent code there, I was just hoping to be able to package it up to make it more easily reusable (outside of using a yaml template).

[woile]

But you can still reuse the same code to get the next version, right?

NEXT=$(cz bump --git-output-to-stderr --dry-run | grep 'tag to create:' | grep -Eo '[0-9].+')
CURRENT=$(cz version -p)

Would that work? Is there anything else you are doing with the action? I'd rather add a cz version --next than adding the hooks if that's the only thing, thoughts?

[Clockwork-Muse]

Ah, no.
Other actions can be things like triggering docker build/tag, publish of a package, etc. I'm doing all of these things, and while it's possible to do them all as simple commands, it would be useful to see that as part of the dry run.

[Clockwork-Muse]

Separately a "get next version" command would be nice, but I want to enable more than just dealing with that.

[woile]

Mmmm it feels like stretching commitizen too much to be honest. As a maintainer of the project, adding python hooks which would run inside commitizen seems like a huge burden, I can only imagine the endless error reports we would get.

What about inverting your design?

1. tag new version and create changelog
2. biuld image with new tag and publish package

That's how I usually go about it, and you can use "release candidates" if you want to check things first.

Thoughts on this @Lee-W ?

[Clockwork-Muse]

I've done that before, yes, but was hoping to avoid rebuilds on a tag/bump-only commit (I've turned off file bumps, and only use SCM integration).

I guess there's really two asks here, and I want both of them:

1. Some way to run hooks even when dry-run is specified.
2. Some way to use python-based hooks.

I feel like I'd prefer 1 to be implemented in terms of 2, because it would allow specifying parameters better, but it's not strictly required....

[Lee-W]

Mmmm it feels like stretching commitizen too much to be honest. As a maintainer of the project, adding python hooks which would run inside commitizen seems like a huge burden, I can only imagine the endless error reports we would get.

What about inverting your design?

1. tag new version and create changelog

2. biuld image with new tag and publish package

That's how I usually go about it, and you can use "release candidates" if you want to check things first.

Thoughts on this @Lee-W ?

Yep, agree. I think adding such python hooks would be a huge burden. But I think "get next version" is a really handy feature (which I might need myself as well). Instead of supporting such arbitrary Python code, maybe we can consider this?

[Lee-W]

I've done that before, yes, but was hoping to avoid rebuilds on a tag/bump-only commit (I've turned off file bumps, and only use SCM integration).

I guess there's really two asks here, and I want both of them:

1. Some way to run hooks even when dry-run is specified.

2. Some way to use python-based hooks.

I feel like I'd prefer 1 to be implemented in terms of 2, because it would allow specifying parameters better, but it's not strictly required....

I would prefer 1 as well

[Clockwork-Muse]

@Lee-W - what is it you're waiting for from me?

In the absence of python hooks, this feature request was mostly about having a way to run hooks during dry-run.