-
-
Notifications
You must be signed in to change notification settings - Fork 297
getting merge conflicts in .cz.toml #977
-
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:
- when I merge dev into staging, I will get a merge conflict in the .cz.toml, which actually makes sense
- 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.
Beta Was this translation helpful? Give feedback.
All reactions
Replies: 1 comment 6 replies
-
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.
Beta Was this translation helpful? Give feedback.
All reactions
-
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.
Beta Was this translation helpful? Give feedback.
All reactions
-
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?
Beta Was this translation helpful? Give feedback.
All reactions
-
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?
Beta Was this translation helpful? Give feedback.
All reactions
-
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
Beta Was this translation helpful? Give feedback.
All reactions
-
We may have to make it available
Beta Was this translation helpful? Give feedback.
All reactions
-
👍 1