-
-
Notifications
You must be signed in to change notification settings - Fork 297
-
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 :)
Beta Was this translation helpful? Give feedback.
All reactions
Replies: 6 comments 5 replies
-
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!
Beta Was this translation helpful? Give feedback.
All reactions
-
Beta Was this translation helpful? Give feedback.
All reactions
-
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. :)
Beta Was this translation helpful? Give feedback.
All reactions
-
👍 1
-
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
Beta Was this translation helpful? Give feedback.
All reactions
-
👍 1
-
I will check this. :)
Beta Was this translation helpful? Give feedback.
All reactions
-
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
Beta Was this translation helpful? Give feedback.
All reactions
-
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?
Beta Was this translation helpful? Give feedback.
All reactions
-
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 ?
Beta Was this translation helpful? Give feedback.
All reactions
-
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
Beta Was this translation helpful? Give feedback.
All reactions
-
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
Beta Was this translation helpful? Give feedback.
All reactions
-
Beta Was this translation helpful? Give feedback.