getting merge conflicts in .cz.toml

[dave-bakker]

I'm trying to get commitizen to fit my workflow. and I'm obviously mis-using it.
We have several branches (dev/staging/prod), people merge their branches to dev, then at some point dev merges to staging, and staging to prod, natch.
I have github set up with build configs for each branch, with dev getting prerelease: alpha, staging getting prerelease: rc, and prod nothing.
My goal was to have, for example dev have 1.5.6a0 merge to staging as 1.5.6rc0, which becomes 1.5.0 in prod. This way I could, for example, go back and debug a production issue with 1.5.0 by putting 1.5.0rc0 in staging

I have 2 issues:

1. when I merge dev into staging, I will get a merge conflict in the .cz.toml, which actually makes sense
2. how can I track dev builds (like 1.5.6a3 becomes 1.5.6rc0)
   am I just overcomplicating things? I need all of the builds tagged by environment because they can only be deployed in their environments.

[woile]

Hi there! I'm having trouble following the versions, you mention that you are preparing a release candidate for 1.5.6, which you call 1.5.6rc0, but then you want to make that into 1.5.0? can you explain a bit more how would that work?

If you merge your 1.5.6rc0 to the prod branch, and then prod branch runs cz bump there shouldn't be any conflicts, cz should create the new commit with the updated version I believe.

[dave-bakker]

cz doesn't create the new commit for me, unless I'm doing it wrong:

 ~/code/test- [staging] $ git merge develop 
Updating a2ff3e1..4a5271d
Fast-forward
 .cz.toml  | 2 +-
 README.md | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)
~/code/test- [staging] $ cz bump
[NO_COMMITS_FOUND]
No new commits found.

[dave-bakker]

the workflow is like this:
dev gets tagged something liek 1.5.6a0,
then when that merges to staging that gets tagged 1.5.6rc0,
then in prod (main), that becomes 1.5.6
so far so good, but when there is a 1.5.6a1, that gets merged and it tries to build 1.5.6rc0, which already exists.
why doesn't 1.5.6a1 become 1.5.6rc1?

[woile]

I think I understand your problem, this is something that can happen indeed. It doesn't become 1.5.6rc1 because commitizen doesn't make assumptions.
A possible solution, is to pass the build number to commitizen when bumping the release candidates, see the docs:
https://commitizen-tools.github.io/commitizen/tutorials/dev_releases/#example-2-github

Would that help?

[dave-bakker]

That would indeed help. now I need to figure out how to use --devrelease in github actions. It doesn't seem to be an option in commitizen-tools

[woile]

We may have to make it available