With the recent Gitea update, parent repos (E.g. `blender/blender`) do
not have "parents" listed in the information gathered by API anymore.
This has lead to the weekly report script encountering errors if the
user has committed directly to a parent repo. This commit fixes that.
Pull Request: https://projects.blender.org/blender/blender/pulls/142701
Add a new CLI option `--date YYYY-MM-DD` to the weekly log generator. Using
it will make it ignore the `--weeks-ago` parameter, and just show the
activity for that specific day.
This is just something I personally found useful, to occasionally inspect
a specific date (WBSO daily log).
Pull Request: https://projects.blender.org/blender/blender/pulls/141281
Since ec141ba3ff, commits from all branches are listed. Issue is that
commits from different repositories and branches will be mixed.
Personally I prefer grouping commits better, so I always edit the output
manually.
With this, commits will be grouped by branch, or PR if one can be found.
The branches and commits will then be printed under their target
repository. This isn't the owning repository of the branch or PR (often
people's personal fork), but the one it targets. This worked much better
in own tests.
Further:
- For some common repositories more readable names are used, e.g.
"Blender Manual" instead of "blender/blender-manual".
- Commits of the Blender repository are listed first, without grouping
under a `blender/blender`.
- Commits to each repository's main branch are listed first, directly
under the repository grouping.
- See PR for a textual mockup of the output format.
Pull Request: https://projects.blender.org/blender/blender/pulls/138615
Currently the script only includes commits to "main" branches. Much of
people's work is done in branches however, so developers either
customized the script, or they would manually go through own history to
find remaining commits (I asked some).
Even if some people prefer to only list main branch commits, it's much
easier to simply remove some commits than to add missing ones.
To be able to tell which branch a commit was on, this adds a " on
`branch-name`" after the commit hash. Personally I don't find this
optimal, I'd rather group commits under their repository/branch,
proposed separately in #138615.
Pull Request: https://projects.blender.org/blender/blender/pulls/138612
When filtering events by labels and not passing an `event_type`, events
that don't pass the label check would be returned. See #134331.
Mistake in 5de40adc9e.
Also clarify behavior in function comment.
Two fixes/improvements to `gitea_json_issue_events_filter()`:
- The `username` parameter would be optional, but not setting it would
make the function do nothing. Ignore it if not set.
- Not passing `event_type` (and not passing `labels`) would make the
function do nothing. It wasn't optional strictly speaking but the
default was an empty set, which is more or less the same. Make it
properly optional so not specifying an event-type will return events
of any type.
- Suppress progress and waiting for input() when the output
isn't a TTY.
- Use a print_progress utility function that adds trailing space
instead of including is as part of the string.
The python script checks on reports based on the provided severity (default High) and sorts them per module.
Thanks to Sybren for suggestions on how to improve it!
Pull Request: https://projects.blender.org/blender/blender/pulls/120022
So far this would include commits committed by the given user, but
authored by someone else. Unfotunately we can't use email addresses to
filter these out, since we can't get the email addresses associated with
an account from gitea, or do a user lookup by email. In my testing the
commit author email and the publicly visible account email would
mismatch in most cases.
Adds a `--weeks-ago` option to be able to control which week the report
should be made for. In practice people sometimes need to create reports
for a few weeks ago or for the current week.
