-
-
Notifications
You must be signed in to change notification settings - Fork 3
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
Consider modifying an existing NEWS fragments as acceptable #35
Comments
@pradyunsg does I'm not sure that "an old change note modified" is an equally acceptable marker of a change note presence in a PR. Though, this could probably be hidden behind a toggle. I just want to make sure that a generic solution we'd come up with is acceptable for other end-users, not just pip. WDYT? Any ideas? |
I think it's good to consider "modifed an existing changelog file" to be a reason to consider this check to be a success. It's the behaviour of If we do decide to add a toggle for this, I don't have a strong sentiment toward what the default of that toggle should be -- either option works. |
Well, the default would be the current status quo so that it doesn't break existing users... |
This wasn't what browntruck implemented, though. Hence the current behavior. |
The check in browntruck is "not removed" which is logically equivalent to "added or modified". |
IMO this entire section... chronographer-github-app/chronographer/event_handlers.py Lines 280 to 309 in 6f275b2
can be replaced with... news_fragments_added = [
f for f in diff
if _tc_fragment_re.search(f.path) and not f.is_removed_file
]
report_success = bool(news_fragments_added) Although, I'd say |
For the release PR case, I think you can check if the destination changelog file itself has been added/modified. If it has been, that's maybe also good-enough? |
See pypa/pip#11879, which modifies a news/ fragment and thus does the correct effect on the changelog.
The text was updated successfully, but these errors were encountered: