Generate simple markdown changelogs for GitHub repositories written in Python.
This package does two things:
Note: This is a really young tool so it might change a bit over time.
The easiest way to install this package is via
pip install github-activity
The easiest way to use
github-activity to generate activity markdown is to use
the command-line interface. It takes the following form:
github-activity [<org>/<repo>] --since <date or ref> --until <date or ref>
See the github-activity documentation for more information.
The easiest way to run the test suite is using
This will install the local version of the package and run the test suite.
nox -s test
This makes major updates to our documentation to add more information for contributors, and to make it easier to parse.
I'll get the tests passing, but wanted to get this up to confirm that @blink1073 and @minrk think this would be a useful addition to help others get started!
Our documentation is fairly sparse, mostly fitting on a single page. However, now more people are contributing to it, and I think it's worth fleshing out this information more so that it's easier for others to learn how to use and contribute to this package.
I'll try to give this a shot relatively soon as I think I have the most context for how everything is set up!
In several of our projects, we backport fixes to a previous release while working on a major release in main - it would be useful to be able to exclude the backported PR so the change doesn't appear twice or give the misleading indication that a feature or bugfix originally made on the development branch for 4.0 was not also released in e.g. 3.1.
For example, in making the changelog for JupyterHub 4.0, I get in the enhancements:
when none of these should be included as changes in 4.0.
so each backported change is present twice, when what I want is for none of these 4 entries. (
-b main excludes the backports, but I currently like to include them because it helps with the manual deletions of the duplicates!)
A simple version would be to allow excluding on a specific label (or label pattern). Doing this by default might present problems, because the exclusions might be the opposite of what you want for the backport release. If you use backport-pr tools like mrmeeseeks (or manual backporting with a separate PR), though, this shouldn't be an issue because the change already appears twice as two separate PRs, and only the 'mainline' PR should be excluded, which would be the one with the label.
GitHub's GraphQL API will restrict any calls to 1000 total nodes. This means that a really large query (e.g. all of the history of a project) will be cut off at 1000 items.
To get around this, we could detect when a query has > 1000 nodes, and split up the call to fetch the data into multiple queries. This is similar to how our "pagination" works, but would be across queries rather than pages of the same query. We might be able to use
dates for this as an easy first step.
I ended up observing a PR included in the changelog, even though it was part of the previous tagged release. To reproduce this, one can do...
github-activity --since v3.0.5 --target jupyterhub/action-k3s-helm
I would expect that PR 73 should not have been written out to the changelog.
* 76875ff - Merge pull request #74 from manics/release.md (3 months ago) <Erik Sundell>
| * c657404 - Add RELEASE.md (3 months ago) <Simon Li>
* d3c165a - (tag: v3.0.5) Merge pull request #73 from manics/calico-3.24 (3 months ago) <Simon Li>
| * e74b367 - Changelog for v3.0.5 - 2022-08-21 (3 months ago) <Simon Li>
| * 9b2415e - Update component versions in README (3 months ago) <Simon Li>
| * 903f39c - Calico 3.24.0 (3 months ago) <Simon Li>
A motivation to think of this as a bug is that the comparison we link to, will not include the changes part of the commit that was most recently tagged.
I see great value in the ability to communicate changes via the version numbers according to a semver2 practice, but that is very hard to do when stuck at
0.x.y as there is no clear practice for that situation.
What do you think about going for 1.0.0 as next release, or next non-patch release?
Full Changelog: https://github.com/executablebooks/github-activity/compare/v0.2.0...v0.3.0
_get_latest_tagshould use the remote repo #52 (@manics)
(GitHub contributors page for this release)
@blink1073 | @choldgraf | @consideRatio | @manics | @minrk | @welcome
(GitHub contributors page for this release)
@choldgraf | @consideRatio | @minrk | @welcome
Add MANIFEST, to include files in distribution
An open collaboration to create executable books with JupyterGitHub Repository Homepage