-
-
Notifications
You must be signed in to change notification settings - Fork 302
docs(config): split the configuration documentation into pages #1657
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1657 +/- ##
==========================================
+ Coverage 97.33% 98.68% +1.34%
==========================================
Files 42 60 +18
Lines 2104 2656 +552
==========================================
+ Hits 2048 2621 +573
+ Misses 56 35 -21
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
d2a6dbe to
92fdf20
Compare
|
I need time to review and improve it. |
docs/config/configuration_file.md
Outdated
|
|
||
| ## Creating a Configuration File | ||
|
|
||
| You can create a configuration file manually, or use Commitizen's interactive init command: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| You can create a configuration file manually, or use Commitizen's interactive init command: | |
| You can create a configuration file manually, or use Commitizen's interactive `init` command: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or
| You can create a configuration file manually, or use Commitizen's interactive init command: | |
| You can create a configuration file manually, or use Commitizen's interactive initialization command: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or just remove the init
or "It is recommended to create a configuration file via our cz init command." and add a link to init documentation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or "It is recommended to create a configuration file via our cz init command." and add a link to init documentation
This is also good
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Creating a file manually sounds too advanced..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or maybe we could add a link to the configuration page and not emphasize the manual creation part too much.
| version = "0.1.0" # Managed by Commitizen | ||
| ``` | ||
|
|
||
| ### `poetry` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this only make sense for poetry < 2.0. for poetry >= 2.0, pep621 is suggested
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you provide details or suggested changes? Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, the following format is more for poetry < 2.0 or users that need specific poetry features. Most people using poetry >= 2.0 are suggested to use pep621
|
|
||
| ### `uv` | ||
|
|
||
| Manages version in both `pyproject.toml` (`project.version`) and `uv.lock` (`package.version` for the matching package name). This ensures consistency between your project metadata and lock file. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It basically follows PEP621, would be better if we mention that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you provide suggested changes? Thanks
f1ac47b to
01c0409
Compare
|
Now it is ready for review. I will probably use AI to improve the wording in the documentation in some future PRs. Let's improve the structure first. |
01c0409 to
449ac4d
Compare
| 1. `pyproject.toml` (in the `[tool.commitizen]` section) | ||
| 2. `.cz.toml` | ||
| 3. `.cz.json` | ||
| 4. `cz.json` | ||
| 5. `.cz.yaml` | ||
| 6. `cz.yaml` | ||
| 7. `cz.toml` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting order... but I just verified it's correc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can be another discussion ... the order doesn't make sense to me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder should we throw a warning if there are multiple cz.* file. Not sure how other tools like eslint or prettier handles multiple configuration file edge case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, that would be a nice feature. 👍
| version = "0.1.0" # Managed by Commitizen | ||
| ``` | ||
|
|
||
| ### `poetry` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, the following format is more for poetry < 2.0 or users that need specific poetry features. Most people using poetry >= 2.0 are suggested to use pep621
b5c3f96 to
54d9e58
Compare
Co-authored-by: Wei Lee <weilee.rx@gmail.com>
54d9e58 to
2fa81c7
Compare
|
|
||
| See [Version Schemes](#version-schemes-version-scheme). | ||
|
|
||
| ## Avoid raising errors |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this can be in a separate page, like CI tutorial page
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But probably in another PR if we want to do it

Why
docs/config.mdbasically mixed the usage of options that is only used by different cz commands together. It would be better if those options are categorized.Also, duplication of option usage documentation occurs. It should be fixed.
This PR categorized and centralizes those configuration file options, and remove the duplication of option usages.
The configuration file doc and version provider doc have their own pages now.
Checklist
Documentation Changes
poetry doclocally to ensure the documentation pages renders correctly