We’ve been working on the GitHub autodata integration recently. See some recent UVIs like one about not missing commits and one about removing the ability to track all commits across all repos you’re allowed to commit to, while we make things more robust.
See also the help doc on Gitminder.
We wanted to make a thread here to keep y’all up to date on this and also hear use cases and bug reports.
Additional background: The API we’ve been using to track “all commits” is github’s events api. The documentation for this now (I mean, since sometime between 2012ish and now) that says it should not be expected to act as a realtime endpoint, and could have delays of up to 6 hours. This spells bad news for edgeskating Beeminders relying on it.
So for the time being we’ve removed the “all commits” option, and we’re looking into possible mitigations or alternatives. Two ideas:
The former approach would presumably result in functionality pretty similar to the former all-commits minding behavior. However, it’s possible that it might not be practical in reality? I haven’t yet looked into how github’s graphql api handles ratelimiting and such, but it’s conceivable that if every time we ran this query it had to look through every repo a person’s ever committed to, it might be costly?
The latter would involve things that would probably make the integration for single repos more desirable/functional anyway, like adding specific branch support (instead of “only the main branch”), and settings for removing or adding repos to the goal. But it would require more active fiddling from the user, requiring you to add new branches or repositories as you started working on them. And it could still run into a similar problem with costly (in terms of our rate limits) queries of many many repos, though probably we could cross that bridge when we come to it?