Find a good strategy CI

[slamer59]

Hello,
I am strugguling to find a way to implement commitizen into a CI workflow.

What are the command to bump for each branch in something similar to git flow ?

If I cz bump in develop and main like in the gitlab CI, I will end with two times the same tag, no ? After merging this branch to main.

Sorry it's the first time I tried to implement it end to end :)

[woile]

Could you expand more with some examples? I'm not sure if you want to create a tag per branch, or just struggling with bumping a single branch (main). Thanks!

[slamer59]

I would like to tag develop branch and main branch. So lets say the branch main is a at 0.1.0 Then I fix + and introduce a breaking change in dev. So in dev I attend something like 1.0.0.dev (or similar). Then I merge to main and would expect 1.0.0. How can I do that ? Le jeu. 20 oct. 2022, 15:32, Santiago Fraire Willemoes < ***@***.***> a écrit :

…

Could you expand more with some examples? I'm not sure if you want to create a tag per branch, or just struggling with bumping a single branch ( main). Thanks! — Reply to this email directly, view it on GitHub <#611 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGA4VSCOLNMIPHEFTR22FQTWEFCWZANCNFSM6AAAAAARKDX73Y> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>

[slamer59]

Hello,
the more I go deep into understanding git flow strategy, github flow, gitlab flow, etc...
The more I think I need only to version the main branch and tag the develop branch as latest.
I am using it for a SaaS and having a CI/CD for it with intermediate environment. At the end, it is a huge complexity for me to introduce intermediate sem-versions as said in gitlab flow.

But for my knowledge, I would be interested by someone explaining me how to do it for a gitlab flow (if possible) or a git flow. If you have the most complex, you can simplify better for you need :)

At the end, it may be out of commitizen scope but having a working example would be a must.
Have a nice day. :)

[Lee-W]

I think pre-release might be something you're looking for. But I'm not a user of this functionality either, not sure whether this can solve your problem

[slamer59]

I will check this. :)

[woile]

I never saw this discussion sorry. Your hunch is right. IMO versioning the main branch is the most straightforward way. If you need "external" access to your library (let's say you have an open source package and you want people to test it), then you could "offer" prerelease versions per branch, but you'll have to attach something unique like pr number. But if you need to create something like a preview environment for other teammates to test, you can just make a release using the pr number and only make a "production" release (bumping) when you merge to the main branch.
That's what I do, I create preview domains with a pr number and I tag my preview docker image with the pr id or similar.

Let me know if it helps

[brad-getpassport]

So I am experimenting with Commitizen and saw this discussion and here is an example of what I would like to do (similar) and like to know how to make this happen:

• Developer works in feature branch
• Developer creates a PR, it gets approved and merges to branch ALPHA
• Developer then creates a new PR for branch RC it gets approved and merged
• Developer then creates a new PR for branch MAIN which gets approved and merged

I would like the change on ALPHA to have revision: 0.1.0.a1
I would like the change on RC to have revision: 0.1.0.rc1
I would like the change on MAIN to have revision like: 0.1.0

I've noticed that when playing with the tool I can get the 0.1.0a1 version but when the PR moves up to RC branch, we don't get another bump because the commit histories are the same.

What's a recommended solution for this?

[woile]

We don't have a recommended solution for this case, because we haven't seen this pattern often enough.

You can actually go from 0.1.0a1 to 0.1.0 by doing an explicit bump:

❯ touch t
❯ git add t
❯ git commit -am "feat: add t"
❯ cz bump --changelog --prerelease alpha             
bump: version 0.4.0a0 → 0.4.0a1
tag to create: 0.4.0a1

[main 2a47d65] bump: version 0.4.0a0 → 0.4.0a1
2 files changed, 7 insertions(+), 1 deletion(-)

Done!

❯ cz bump --increment MINOR
bump: version 0.4.0a1 → 0.4.0
tag to create: 0.4.0
increment detected: MINOR

[main e1dfc27] bump: version 0.4.0a1 → 0.4.0
1 file changed, 1 insertion(+), 1 deletion(-)

Done!

I'm thinking commitizen should be smart enough to identify that it is under a prerelease and it should not expect commits.

Possible with no commits:

0.1.0a0 -> 0.1.0rc0
0.1.0a0 -> 0.1.0
0.1.0rc0 -> 0.1.0

Not possible with no commits:

0.1.0 -> 0.1.0a0
0.1.0 -> 0.1.0rc0
0.1.0 -> 0.2.0

Or alternatively, when given the flag --prerelease it should behave similar to a manual --increment without expecting commits.

Thoughts on this @Lee-W ?

[brad-getpassport]

Thanks @woile , I tired this example with the --increment minor and here's what I see happens:

(.venv) features % cz bump --changelog --yes  --prerelease rc --increment minor
bump: release 0.4.0a0 → 0.4.0rc0

Automatically generated by Commitizen.

tag to create: v0.4.0rc0

No commits found

[eduardocardoso]

I did a little digging and found that it was failing at the changelog generation step, the version bump already allows for this case.
Did a PR to fix the changelog generation

[brad-getpassport]

@woile @Lee-W Any thoughts on this?