cli
cli copied to clipboard
all-contributors
Report when Github rate limit is telling you < 10 left
Was adding everyone to my project when suddenly I got rate limited.
https://api.github.com/rate_limit was at zero.
If I had known, I wouldn't have been using the command the same way. I would have edited the file manually to keep my existing Github rate for important things like lookup.
I think a warning when you're down to your last 10 requests would be helpful.
Maybe it'd be even more useful if we could add more than one at a time and use the graphql API to get all the info at once?
GitHub API v4 (GraphQL) doesn't allow unauthenticated requests as far as I know.
I've been wondering about using dotenv to allow maintainer to declare an oAuth token for the REST API and read/use it for all GH requests.
Opinions?
Hmmm... This really should only be necessary one time, so what if we just had them set an environment variable?
Also, I wonder if the current API can be used to get multiple user info at once 🤔
It's possible but only for contributors: https://api.github.com/repos/gitpoint/git-point/contributors?per_page=100 or collaborators: https://api.github.com/repos/gitpoint/git-point/collaborators?per_page=100 (requires auth)
This is what I used to code the new check command. There's no current REST endpoint that receives an arbitrary multiple users logins and outputs their information (this is what GraphQL was built to solve afaik)
We could re-use check code in init to populate contributors initially.
(GH contributor = at least one commit to the repo.)
We would have no way to know what was the commit about, so we would be adding code for everyone here, and the maintainer would have to sort that off manually afterwards.
I've been wondering about using dotenv to allow the maintainer to declare an OAuth token for the REST API and read/use it for all GH requests.
Asking users to set an env var or passing a token at the CLI are common practices so it shouldn't be a problem.
We could re-use check code in init to populate contributors initially. (GH contributor = at least one commit to the repo.) We would have no way to know what was the commit about, so we would be adding code for everyone here, and the maintainer would have to sort that off manually afterward.
My PR for #117 would (partially) handle this issue as it'd know who's a code author vs. who's a bug author. Beyond that, things like doc, design, test etc. would need to be sorted out manually since they are all "code" as far as git commits are concerned. And same goes for any other types that are not code or bugs as we don't have a way of extracting that information from any API (maybe in future there will be an A.I based endpoint for this 😉). It should still be a big help as it is considerably less work to change the type than having to add everything manually (during init).
@mrchief For things like doc, test and design, there should be a way to distinguish those from code but then that's something we could tackle down the line once your PR is in place and works for bug and code.
What I mean by that is that, say the CLI program (and later on the bot itself), knows how to recognise code contributors and bug reporters. It will be able to classify like this.
Agreed.
What I mean by that is that, say the CLI program (and later on the bot itself), knows how to recognise code contributors and bug reporters. It will be able to classify like this.
Guess the cli can run some heuristics to detect changes to documentation (like .md, .txt etc. files or docs folder) and so on maybe? Anyway, that's down the line for sure.
@mrchief Yes, it could. I'm not that familiar with that part of GH's API but there's surely a way to see information about commits (e.g: which files were modified or/and what were the modifications).
@Berkmann18 Yes there is. It's just that heuristics-based scanning is like a rabbit hole :)