commitizen
commitizen copied to clipboard
commitizen-tools
Add support for scoped changelog generation: cz changelog --scope myscope
Description
Consider a monorepo with multiple projects (e.g. proja and projb), each project with its own .cz.toml file. Commits are scoped according to project, e.g:
fix(proja): some fix in proja
fix(projb): some fix in projb
The changelog for proja, should ignore all commits except those scoped with proja.
Possible Solution
This could be achieved by setting scope = proja in the proja/.cz.toml file, or by running cz changelog --scope proja. This means that only commit messages with the specified scope will be considered when generating the changelog.
Additional context
No response
Additional context
No response
I'm might not be a user of this feature but I'm ok with it. @Woile What do you think?
I like the idea, it's quite interesting. I think we should also have a stance on how to use commitizen with a monorepo. If you create multiple changelogs, are you also supposed to create multiple tags? I understand that with this feature we could create a changelog per package, but what happens with tags and version management should also be answered.
+1 for this. Been trying to use commitizen in a monorepo setup, without much success..
From what I understand, git tags can be organized in directories and files, e.g
myapp1/1.0.0
myapp1/1.0.1
...
myapp2/2.1.0
myapp2/2.2.0
c.f. https://stackoverflow.com/a/56558343
Would love for this to become a reality!
I am looking at using commitizen in a monorepo too and I hit issues when trying to do this by using different tag_format to allow different tags to work. I discovered there is an issue where the change log is not generated due to the tag names in the changeling file not matching other tags with the same version name in them (I am going to do a PR which should fix this).
While testing the fix locally I found the issue with commits from different components where then included in the changeling which made them hard to understand. I have solved this issue by using a custom config with changelog_pattern set to include the component name.
If it is useful I can try to create an example repo layout to demonstrate this
That'd be really nice, I'd like to see an example with what we currently have
That'd be really nice, I'd like to see an example with what we currently have
@woile so this isn't strictly with what we have now it would need the fix I am proposing for changelog generation with tag_format in #995 that I have raised. I used that version to do all the tag/changlogs in this repo.
I kept it simple just using 2 directories each with an independent config. Be great to hear your thoughts on this approach.
Looks really clever! I like how you use the pattern to define which commits go to which changelog. Most "monorepo" tools end up behaving like that (cargo, npm workspaces, etc)
Some thoughts:
- What happens when someone makes a wrong commit? should it create a root changelog?
- Do you need to run commitizen one per folder, right?
- How to address bumping only packages that have received changes?
I'm thinking that we could experiment in a new package for monorepos with cz.
Where at the root of your project, you add a .cz.toml with
[tool.commitizen.workspace]
members = [
"packages/*",
"legacy_one"
]
and then run:
cz workspace bump
and it goes to each member and bumps and creates changelog, if necessary.
To identify if things have changed, one option is to use get_commits args from commitizen and filter per folder.
Example on commitizen repo:
git -c log.showSignature=False log --pretty=%H%n%s%n%an%n%ae%n%b----------commit-delimiter---------- \
-- commitizen/commands/*
We could try adding a new config parameter to commitizen to bump based on files changed 🤔
Our CI validates that the commits only have files for the component in the scope, build fails so that doesn't get to trunk and won't be released.
We are also quite strict keeping PRs scoped to one component, then the component with changes is the only ones built and released.
The idea of adding some of this logic to commitizen is interesting, my thought was to leave that detection to the build toolset and use commitizen for version bump/conventional commit validation. The idea looks interesting and I might have a play around with it.
I like this idea. For monorepos it's a game changer. I think both aspect are needed:
- possibility to bump multiple components from workspace at once
- possibility to bump a single component independently
Having the ability to generate scope-based changelog (including a scope prefix handling to be able to handle things like feat(proj-a/scope): with --scope "proj-a/*".
Project having this kind of workflow often rely on tag in the form of component-a-vX.Y.Z but tag pattern is already properly handled
