-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Unfixable failure when the dep tree includes a dependency circle and one of those deps at one time referenced a broken module #3526
Comments
Here's another error I just saw in repo
Again, note how many times the tree walking yo-yo's between |
I think we just shell out to |
We are a GitHub enterprise customer, and I have to be careful about what I can post publicly, so this may be easier to debug via a GitHub private support ticket between you and my @jeffwidman-ns account where I don't have to be paranoid about redacting everything... that way you may also be able to directly see the relevant Here's some examples:
Basically, if I'm understanding this correctly, because of the circular dependency, that broken dep will always be reachable because dependabot just keeps yo-yo'ing between older and older versions that depend on each other until it finally finds the version that pulls in the broken dep which causes We would really like to get to the bottom of this and get it fixed, so just let me know what I can do to assist here. |
Thanks, yeah that error comes straight from |
Sounds good, I opened ticket 1117886. |
So the upshot of our email discussion was that the error was being thrown by However, I was able to replicate the issue using the docker development container. From there, I noticed a few things. Dependabot today manually edits the But if I ran Additionally, once the error started appearing, it would pretty much always start appearing. I ran I tried a lot of variants to "pre-warm" the module cache such as running Anyway, I'm 100% confident I don't fully understand the And also, it was very clear that manually editing I applied that as a fix in #3590, and it completely solves the problem. I tried multiple repos, all of which are currently failing on dependabot github native, and they all started working with that fix. |
Hi @jeffwidman, where are we at with this issue, has this been resolved by the changes you've submitted? It's been a minute since we looked into this so I am slightly lost 😄 |
I think the underlying problem here is unfixable on the dependabot side and will be resolved at this point by simply bumping to
However, I was waiting to close this until i could verify... unfortunately the problematic repos where we are hitting this are still on So let's hold this open a few more days until I have more info. |
@jeffwidman I think you meant to link to a different issue, maybe #4423? |
A particular
go
library has a very convoluted dep tree:Unfortunately C also depends on another repo that released a version of their library that they later removed, so it broke the
go.sum
checks: grpc/grpc-go#3945Breaking this cycle of dependabot death has been a royal pain. It's easy to bump the broken version within C. But then when dependabot tries to walk the deps of the current (fixed) C, it finds D, then finds A, which relies on an older version of C which is broken.
Literally I'm seeing error messages in repo A that look like:
I've been manually unrolling the loop by slowly bumping things and cutting new versions, but I was wondering if there was a more efficient way to resolve this?
I was a bit surprised in the above error message to see Dependabot ping-ponging between older and older versions of the same library... shouldn't it be smart enough to cache the first time it sees a library version pin and if it later sees older pins of that library to ignore them and eliminate that subtree as completely irrelevant?
Additionally,
go.mod
supports the concept of// indirect
whereby I can specify a minimum version for a dep of a dep... If dependabot prunes subtrees for older versions, then in the top-level repo I could add some// indirect
pins which would force dependabot's tree walker to simply skip old/broken versions of underlying deps.In addition to making it faster to unbreak things, it'd also speed up the dep runs significantly.
I am unclear if this is a bug, or desired behavior...
The only reason I could see it being expected behavior is to guard against an edge case where a dep pins a dep which is incompatible with another dep... but again, if the parent dep has already pinned a library version, then somewhere a human has already explicitly said "this is okay". I suppose there may be some really weird edge case where an incompatibility is added after the fact to a newer release of an underlying dep... but there's still got to be some cleaner way to workaround this.
The text was updated successfully, but these errors were encountered: