Closed Kuba314 closed 1 year ago
Thanks for reporting the issue. I've tried with generating an empty list of issues but that works fine for me. Is there any specific config, user, gitlab instance or date range which triggers this? Does it happen for --issues-created
, --issues-commented
, --issues-closed
or all of them?
@psss --gitlab-issues-created
nor --gitlab-issues-closed
don't trigger the error. Only --gitlab-issues-commented
does.
I don't think I'm using any weird configs. For the date range I'm using just a --since
argument.
I've decided to look into this myself. The issue is caused by the Events API saying that I commented on an issue, but that issue is a task, which isn't returned by the Issues API, which causes get_project_issue()
to fail with StopIteration
, because an issue with that ID isn't returned by get_project_issues()
.
The reason this happens only with --gitlab-issues-commented
and not --gitlab-issues-created
or --gitlab-issues-closed
is that the latter 2 are checking for target_type=Note
, but tasks have target_type=WorkItem
, so they don't show up at all.
As per gitlab-org/gitlab#368055, tasks can't be accessed via the REST API yet, so there isn't a way to fix this properly, but at least did
shouldn't raise an Exception.
There are 2 ways to fix this:
Note.iid()
.The second option is better IMO, but it will require to print something else in the summary instead of the iid. Maybe reuse the "unknown" string? Or use #(task {id}
, id being the global ID?
* Issues commented on gitlab: 2
* namespace/project#001 - Issue title
* namespace/project#unknown - Task title
Created a PR for the change I proposed.
Upon interacting with Gitlab work tasks,
did
throws an exception during/after printing theIssues created on gitlab
section.