Chovin
commented
8 years ago another thing is, this issue is "solved" by Github's notification inbox. You see all the events you've missed there.
If each event has the name of the repo in it, you could just accumulate data and distribute to the subscribed users the repos they requested.
I don't see a problem with keeping the events stored somewhere until digest time.
If an API request can get you the event history, you could just read that and send the history up to the last digest. If that's possible, it wouldn't be watching, it'd be checking
if none of that made sense, I apologize. I'll blame it on sleepy
centipeda
I'm asking mostly because of issue #3, for periodic notifications from repositories on GitHub. There are a few ways I've found you can accomplish this -- manually caching all repo data, installing webhooks on each repo, and reporting the notifications you receive when you "watch" a repository as a user.
Attempting to cache the data of the repos you want notifications from is incredibly unwieldy (and raises questions of privacy).
Installing webhooks onto a repo is the most convenient solution and works well, but requires permission from the repo owner to install webhooks. Additionally, there is already integrated support for webhooks within Discord, which already functions with GitHub. I'm going to assume that anyone who wants notifications from GitHub through Discord and has the permission to install webhooks on all the repos they want notifications from would use Discord's builtin stuff.
That leaves the third option, "watching". You can, through the API, set a repo to being "Watched", in the same way you'd click "Watch" on a repository or organization to receive notifications when there's activity. This requires the cog to log in through the API with a GitHub username and password/personal access token. This raises the question of whose account the cog should be granted access to. If the bot owner gives his credentials to the bot and lets users subscribe the bot to arbitrary repos, then the bot owner is now potentially flooded with notifications from repositories he didn't subscribe to himself. The only other option (that I can think of) is to create an entirely new account for the bot and use that account's credentials to log in and subscribe to repos, which seems inconvenient and unnecessary for an application as small as this. Who, then, should the bot authenticate as?
There's probably a much simpler solution staring me in the face, but I can't see it right now. Your thoughts would be appreciated.