-
-
Notifications
You must be signed in to change notification settings - Fork 267
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
problems importing from github.com/nixos/nixpkgs #749
Comments
|
The error is from the github server. But I can tell you what I would try:
I hope that helps. Let us know how it is going. |
We should adress that at some point, any idea why that is? |
Do you remember that discussion: #585 (comment). As far as I understand |
Ha yes, I forgot about that, thanks. |
Hey, thank you for your reply. Just to clarify:
Oh, the reason it's slow is not git-bug; it's github's API ratelimit. I did not mean to imply that git-bug was not performant.
Thanks, I will give those a try tonight or tomorrow. |
Testing now. Is there any way to get |
Hrm, with latest HEAD and
Apparently
|
Decreasing these (as low as 20) did not help.
Increasing this (as high as 10) did not help. Is there any way to get more information about what git-bug was in the middle of doing when the error happened? Like a stack trace maybe? |
I will have look at it, but I will need a few days. In case I do not come back to this issue in about a week, please feel free to ping me. |
@rng-dynamics it might make sense to implement another At this point it would make sense to rename those to |
@a-m-joseph, thanks for the bug report. The errors are seemingly arbitrary errors by github. If you want you can use my draft in #760. Even if there are github errors with #760 the bridge will continue importing the other issues. And you can run the import again and it will try to fetch the remaining issues. Have look at the file |
Thanks, I'm trying this right now. |
It just finished. I'll investigate the results tomorrow (but wow, the issue count looks correct!)
|
Appears to be working! Thank you so much for taking the time to look into this. |
A8DE:54BE:87BAE:9F6E7:62140406
when reporting this issue.
I'm very sorry to trouble you again, I really appreciate the time you've put into this already. Unfortunately after taking a closer look at the results of the import, I have the correct number of bugs, but:
The Even weirder, the bridge is importing dates correctly, but they don't seem to be used when sorting! For example,
Again, I'm really sorry to pester you over this, I feel like I've already really pushed the boundaries of your generosity with your time. Unfortunately I don't know go, so debugging this myself is not really feasible. In the event that this isn't something you can spend any more time on (which I completely understand), do you consider git-bug's repository format to be stable enough that it is okay for people to write bridges which aren't distributed as part of the git-bug codebase? I can probably spare enough time to write a really good github importer, one that also imports pull requests (which github apparently treats as a special kind of bug). Unfortunately I can't really take on learning a whole new programming language and ecosystem right now, that's a much larger time commitment. |
Regarding the github bridge: The Github API is quite fragile and we are trying to keep up with its repeatedly changing quirks. The code which you used is only a draft merge request. Anyway, for my own convenience I used a file
The bridge will update the file according to the import status. After the import the file might look as follows.
If you would run the import again, it would read the file again and it would try only to import issue 65, which has failed in the previous import. The other problems which you describe are probably not caused by the importer but some other component in git-bug. I would actually really appreciate input on how to improve the importer. My main headaches with the importer are (1) the fragility and changing error-behaviour of the GitHub GraphQL API, and (2) the user interface/interaction in case of errors during the import. How could we get closer to that really good importer? |
Thank you for explaining this. Personally, I much prefer the sort of workflow the Linux kernel uses, where inter-developer communication uses simple protocols and the developers themselves select the complex tools that suit them best. Whenever I bring this up in discussions, people always come back with "But GitHub has a usable and reliable API that you can use if you want that!" I've long suspected that this was not, in fact, true. I appreciate your confirmation of this, as someone who has worked on a major integration project with this API.
Mainly I would add several levels of debugging output so I can see what's failing, including: (1) a "here's what I'm doing" log and (2) a wire-protocol dump (interleaved with (1)) |
Anyone know if it's still an issue? |
I don't think that "hope the problem goes away" is really a solution. The problem still exists at 70bd737.
Note that the error above is a github error. Clearly they are trying to say "we need you to rephrase your query, but we are not interested in giving you any hints about how to do that. neener neener." I guess "stop using github for large projects" is really the only viable solution to the fact that github's api does not scale, nor does github care at all about that fact. |
It looks like a temporary failure in the github side (like a burst of request causing a CPU overload, cascading into failing to handle the request) to me. Basically the P99999 that is both hard to track down and fix for cloud engineers. git-bug is doing so much request in that situation that it increase the likelyhood of that happening. The problem is that instead of retrying, git-bug fail entirely. We need to both:
|
I assure you, it is not temporary. I left it running for several days in a loop a while back and it never finished. |
I meant that it's a transient failure on github side, meaning that the exact same request would succeed later, meaning that git-bug is doing a valid request. The problem is in how we handle those random failure. |
Not if some aspect of the failure is really an undocumented ratelimit/cpulimit. I strongly suspect that is the case. |
This bot triages untriaged issues and PRs according to the following rules:
To remove the stale status, you can:
|
Ten minutes ago, trying to
git bug bridge pull
the nixpkgs project's bugs (>5k bugs, >3k PRs -- a very very large set of bugs):I have never been able to get a pull of nixpkgs' bugs to complete, and I've been trying for weeks now (see also #740).
I am using 05d73e1, which has the fix for #585.
Is there any chance that git-bug could keep fetching other bugs when it encounters a problem like this? It appears that it just aborts as soon as any API call produces an error. The nixpkgs bugset is ginormous, so it's going to take me at least a week (due to ratelimits) anyways. But right now it keeps failing after 108 bugs out of 5000+.
Is there an environment variable I can set to cause git-bug to print a backtrace or other context when it gives up like this?
The text was updated successfully, but these errors were encountered: