documaticai / doculog Goto Github PK

Describe the bug
Doculog uses the python package subprocess to run git under the hood to collect commits.
This works fine for linux (i believe macOS as well), but fails with windows because subprocess cannot find.

We have introduced a function to get git from path, but that does not seem to work either (https://github.com/DocumaticAI/doculog/blob/master/doculog/git.py#L13).
We have tried setting shell=True, but that also doesn't seem to work
Can someone please confirm the above?

To Reproduce
Steps to reproduce the behavior:

1. Be on a windows machine
2. Run `subprocess.check_output["git", "log"])
3. This will fail with a FileNotFoundError

Expected behavior
We should be able to get git logs on windows!

A fix to this issue will update doculog/git.py to work on windows and non-windows with the same functionality

Screenshots
None

System:

• OS: windows
• Doculog: all

Additional context
N/A

Is your feature request related to a problem? Please describe.
Sometimes (often) it takes several commits to make one complete feature change. as doculog currently works, this create false positive/duplicate features in the changelog. doculog should interpret

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
None

Additional context
N/A

Is your feature request related to a problem? Please describe.
For changelogs with lots of releases, it would be useful to have an overview of releases in the form on a contents at the top of the document.

Describe the solution you'd like
Add a contents section, with each release as a new entry. Release entries should be of the form - <VERSION> - <DATE, just like their headers. Clicking a release entry jumps you to the relevant release section.

Describe alternatives you've considered
None

Additional context
N/A

Describe the bug
The "Unreleased" section gets git commits in a date range between the last version tag and some future date. The future date used to be 2100-12-31, but this began to yield empty commits for some reason. To circumvent this issue, #17 changed the date to 2099-01-01, which seems to work. On limited testing, only some future dates in 2100-01-DD work.

To Reproduce
Steps to reproduce the behavior:

1. Run git log --since 2021-12-30 --until 2100-12-31 This should not yield anything
2. Run git log --since 2021-12-30 --until 2099-01-01. This should yield commits

Expected behavior
All the commits since the --since date should be returned.
Perhaps the Unreleased section should be updated so it only calls git log with a --since tag but no --until tag. Either that or discover what the issue with git log dates is.

Screenshots
N/A

System:

• OS: ubuntu 20.04
• Python version: 3.8
• Doculog version: 0.1.4

Additional context
N/A

Bug description:

If multiple versions are released on the same day, only the first new version gets changelog updates.
This is happening because doculog searches for commits in a range of dates at day-level granularity. A more precise time must be extracted from git tags in order to differentiate between versions.

To replicate:

Make some changes, then tag with git tag -a "vMAJOR.MINOR.PATCH". Then repeat with a new version. Run doculog and see that no updates are given for the latter version

Is your feature request related to a problem? Please describe.
Some teams use prefixes on their commit messages to indicate the type of change. If prefixes are present, they should take precedence over other categorisation methods

Describe the solution you'd like
In the pyproject config section for doculog, read an optional field which takes a list of key/value pairs for prefix/category. E.g.

[bug] = Fixed
[feat] = Added
[depr] = Deprecated
[misc] =

So a commit [bug] some bug fix would be classified as a "Fixed" action. A prefix could be given an empty category in the config to denote that that action should not be included in the changelog. In the above example, a commit [misc] Some random stuff would not be present in the changelog.

Describe alternatives you've considered
None

Additional context
N/A

Users of doculog with API access get additional features for generate changelogs. The changelog/feature list of the API should be included in this repository to make it clear to users how the behaviour of their doculog tool has changed over time, and what behaviour it currently has

Functionality of doculog relies on git. This makes it difficult to unit test because git cannot, as far as I know, easily have its behaviour altered/mocked for unit tests. It is possible to mock the responses to subprocess calls (which invoke git), but this requires the test writer to create a string of git log/diff output and isn't scalable.

We need to find a way to mock git behaviour for unit testing. I.e. start a git repo local to that test / test suite, easily add commits and tags.

Is your feature request related to a problem? Please describe.
For doculog to update the changelog with a new version, a tag must be created. However, if the changelog is then updated to reflect the new tag, the updated changelog is not included in the new tag. There should be a way to update a changelog as if a new version has been made before adding a tag.

Describe the solution you'd like
Add optional flags to doculog command: --upgrade-major, --upgrade-minor, --upgrade-patch, which will pretend that a tag of the relevant upgrade has been made and make the new changelog accordingly. If more than one of these flags are provided, the most important part of the version takes precedence (i.e. if --upgrade-major and --upgrade-minor, only upgrade major)

Describe alternatives you've considered
You can mess around with tags to get the changelog update in the correct tag, but this is unwieldy and not user-friendly

Additional context
N/A

Is your feature request related to a problem? Please describe.
Each version in the changelog should have space at the top for a brief summary of the release - it's purpose and what it achieved at high-level. Git tags can include a message, which is often appropriate for the changelog version section.

Describe the solution you'd like
If a git tag has a message, it should be included as the changelog version's summary.

Describe alternatives you've considered
N/A

Additional context
N/A

Describe the bug
Some users are reporting getting an invalid API key message, but I've checked their key and it is valid.
The first confirmed reportee was windows, but I'm not sure if it's an OS-specific issue.

If this happens to you, please comment below with your system information (do not post your api key)

To Reproduce
Steps to reproduce the behavior:
N/A. Not easily reproducible as "incorrect" keys work when I try them.

Expected behavior
All valid API keys are recognised as valid