-
-
Notifications
You must be signed in to change notification settings - Fork 323
fix(commands/bump): prevent using incremental changelog when it is set to false in config #996
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?
fix(commands/bump): prevent using incremental changelog when it is set to false in config #996
Conversation
661a140 to
d4894e5
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #996 +/- ##
=======================================
Coverage 97.99% 97.99%
=======================================
Files 60 60
Lines 2691 2693 +2
=======================================
+ Hits 2637 2639 +2
Misses 54 54 ☔ View full report in Codecov by Sentry. |
d4894e5 to
45b9352
Compare
|
Just opening the debate: wouldn't it be easier and more consistent to fix/align the default By adding a fourth settings source of trust (defaults, user settings, cli flags and now mutated settings, fifth if you add the fact that plugins can override some settings), I feel that we are fixing a symptom but making the problem more complex. |
Yeah, I think that would be a better way to address the issue if possible. The implementation would be easier and also could prevent overriding the behaviors from multiple sources when running the |
Could you make a proposal for this? It sounds interesting, would be nice if we can simplify the settings |
|
I'm a bit confused here. I thought we could solve it by reading the value from config? |
I think there are total three combinations of configurations here:
The 1st & 3rd cases would cause ambiguity when we're reading the value from |
I thought the one from the config should overwrite the default. Or did I miss anything? |
|
Hello, Do you guys have any news on this fix ? |
Lee-W
left a comment
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 probably won't say I love this idea, but it is an acceptable workaround before we introduce a better config system. @josix, could you please rebase it and add some tests to verify it?
|
@josix what is the status of this PR? Thanks! |
|
Oh I missed this comment, let me pick this up |
|
Thanks! |
d439c38 to
aef2004
Compare
c2df766 to
5ecaa15
Compare
7162151 to
9c8f89a
Compare
| "incremental": incremental_setting | ||
| if incremental_setting is not None | ||
| else True, |
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 probably also works and is less confusing
| "incremental": incremental_setting | |
| if incremental_setting is not None | |
| else True, | |
| "incremental": self.config.settings.get("changelog_incremental", True), |
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.
yeah, thanks for pointing it out.
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.
weird, seems that it will let tests fail, let me investigate it.
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.
Oh, I found the root cause, dict.get only returns the fallback when the key is missing, so .get(..., True) would return None (not True). The explicit check is required to default to incremental changelog generation while still honoring an explicit False.
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 does remind me that Airflow has an ARG_NOT_SET thing. not sure whether we should have similiar mechanism
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 we'll also need more context in this comment. same as the value in default.py. This is probably the best we can do for the time being, but worth thinking of a abetter solution in the following major versions. also would be great if we have a unit test to cover it
0002ced to
181db46
Compare
181db46 to
0b31a73
Compare
Fix #883
Description
Since the default behavior of
cz bump --changelogis to write incremental changelog, which is different from the default value ofchangelog_incremental, it is hard to know the value is set from user or the default setting, To address it, I created one more member inBaseConfigto record which property is defined from users so that we could distinguish the value is from default setting or users.Checklist
./scripts/formatand./scripts/testlocally to ensure this change passes linter check and testExpected behavior
cz bump --changelogshould work asfalsewhen user configurechangelog_incrementaltofalse.Steps to Test This Pull Request
Modify the CHANGELOG file

Configure
pyproject.tomlwithchangelog_incremental = falseRun
cz bump --changelogCheck the CHANGELOG, which the new added content should be replaced

Additional context
ditto.