-
Notifications
You must be signed in to change notification settings - Fork 127
Description
This is maybe a piece of, or duplicate of, or related to, or... issues #152 and #246 and also PRs #174, #296, and #337. This issue is being created as a clear place to discuss addition of an explicit control between two types of checks and what those checks would do. The other issues either describe a problem and a general request. The PRs (one built from the other) implement weak implicit detection and checks.
Given that the subcommand interface is only available presently in 19.9.0rc1 I think it is ok to change that without deprecation etc (I don't know if the option-based CLI was even deprecated). @energizah suggested that we consider names relating to what the checks do which seems at the very least worth considering. I will be referring to them as the change check and the release check for now without implying any decision against the suggestion. @adiroiban suggested the existing check be documented in the readme first. I think we should know what it does but I'm not sure it needs to go in the readme if we plan to change it or it's surroundings before the next release? We should be sure to remember the -m towncrier interface as well while considering the design of the explicit check-type selection (I say this because I had kind of forgotten about it).
Checks:
- Existing
- Run
git diffagainst the referencetowncrier/src/towncrier/check.py
Line 44 in 70646d9
["git", "diff", "--name-only", comparewith + "..."], cwd=base_directory - If no files changed,
SUCCEEDtowncrier/src/towncrier/check.py
Line 55 in 70646d9
click.echo("On trunk, or no diffs, so no newsfragment required.") - Identify present fragments that differ from the reference (new or modified or renamed or ...?)
towncrier/src/towncrier/check.py
Line 89 in 70646d9
fragments_in_branch = fragments & files - If no fragments differ,
FAIL - If one or more fragments differ,
SUCCEED
- Run
- Change
- Should it change from
Existing? - Maybe add a draft run, or more complete build check
- Should it change from
- Release
- No fragments present
- Release notes modified
- Maybe check more carefully? Presence of expected top line/title given the package version?
- At least do a draft to make sure it doesn't fail, but a stronger check that'll exercise insertion into the release notes
This is just an initial quick list, I started into this a bit later than I ought have.
Just to make sure everyone sees this: @adiroiban, @energizah, @freakboy3742, @tjanez, @vcalvert. Obviously feel free to unsubscribe if you don't want to follow this new issue.