You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Refresh issue timelines when cross-references change (#168)
Cross-references do not change an issue's updated_at, so an incremental
run never lists the issue and never re-fetches its timeline. An issue
can be referenced from another repository years after its last activity
and the backup would never see it.
On incremental runs with --issue-timeline, ask GraphQL for each item's
cross-reference count and newest timestamp, compare both against what is
already saved, and re-fetch the timeline of anything that differs. Items
the since listing did not return are fetched individually. Both values
are needed: the count alone would miss a reference being added and
another deleted between runs, and the timestamp alone would miss a
deletion.
Pull requests are swept too when they are being stored as issues, which
is the case unless --pulls is used. They need their own query because
the issues connection excludes them, and because totalCount ignores the
itemTypes filter on a pull request although it honours it on an issue,
so their cross-references are counted from the nodes instead. Where that
count may have been truncated, the comparison falls back to the
timestamp alone rather than re-fetching on every run.
This costs one rate-limit point per 100 items against the GraphQL quota,
measured at 6 requests for a repository with 528 issues and pull
requests, and stores no new state: the comparison is against the
cross-references already in each item's timeline_data. A GraphQL failure
warns and leaves the rest of the backup unaffected.
Closes#168
Copy file name to clipboardExpand all lines: README.rst
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -366,9 +366,9 @@ Note that timeline entries are not all the same shape as events. ``cross-referen
366
366
367
367
``--issue-timeline`` is included in ``--all``. On issues with many cross-references it can be noticeably larger and slower than ``--issue-events`` alone, because each ``cross-referenced`` entry embeds the referencing issue in full. On a heavily cross-referenced issue this can mean several times the API requests and many times the JSON on disk. Ordinary repositories see little difference.
368
368
369
-
If you enable ``--issue-timeline`` on an existing incremental backup, run once without ``--incremental`` to backfill it. There is no automatic backfill, so an incremental run only revisits recently updated issues and every older issue keeps a JSON file with no ``timeline_data`` until something touches it. The same applies to ``--incremental-by-files``.
369
+
Incremental backups need extra help here, because being referenced from elsewhere does not change an issue's ``updated_at``. An issue can be mentioned from another repository years after its last activity, and the usual ``since`` listing will never report it as changed. On an incremental run with ``--issue-timeline``, github-backup therefore asks GitHub's GraphQL API for each item's cross-reference count and newest timestamp, compares those against what is already saved, and re-fetches the timeline of anything that differs. Pull requests are included in that check when they are being stored as issues, which is the case unless ``--pulls`` is used. The check needs no extra state on disk and also notices references that were later deleted. It costs one rate-limit point per 100 items checked, against GitHub's GraphQL quota, which is separate from the REST one. That is cheap in quota terms even on very large repositories, but it is not instant: a repository with 18,000 issues and pull requests took around 200 points and five minutes for the check alone.
370
370
371
-
Incremental backups select issues by ``updated_at``, and a cross-reference does not change the referenced issue's ``updated_at``. An issue whose only new activity is being referenced elsewhere is therefore not revisited on that run. It corrects itself the next time the issue is touched, since each issue's timeline is fetched in full, so the only lasting gap is an issue that is referenced and then never touched again. Run occasionally without ``--incremental`` if that matters to you.
371
+
If you enable ``--issue-timeline`` on an existing incremental backup, cross-references on older issues are picked up automatically by that check. Timeline entries of other kinds, such as commits and reviews, are only fetched when the issue itself is updated, so run once without ``--incremental`` if you want those filled in for historical issues too.
0 commit comments