Migrator bot opens PRs ignoring number of children? #2961
Comments
h-vetinari
changed the title
|
It's worth noting we needed to pause the migrator1 due to an absence of 1: conda-forge/conda-forge-pinning-feedstock#6361 |
|
I know, but that has no bearing on this issue. |
|
Yeah I have no idea here. Someone will have to load the thing and look at the graph. I won't get to it for a while, but feel free to go ahead. |
|
So numpy is marked as part of a cycle in the graph for python. See this file and this entry "cycles": {
"__set__": true,
"elements": [
"fenics-basix",
"fenics-basix-meta",
"gnuradio",
"gnuradio-soapy",
"heavydb-ext",
"intel-compiler-repack",
"numpy",
"omniscidb",
"pyopencl"
]
},Feedstocks in cycles always go first no matter what. The surprising thing is that the solver checks passed. |
|
The bot also skips solver checks for nodes in cycles. So this PR is expected. |
|
The final bit here is that the bot only opens PRs for things it can solve. So even if it tried a feedstock with more downstream packages, if that one does not solve, it will not make the PR. This explains the rest of the things. I am going to close this issue. Feel free to reopen! |
That seems spurious, numpy shouldn't depend on any of these (I guess there's a longshot that it relies on intel repack through lapack and MKL). Also, omniscidb is archived, so presumably shouldn't be part of any cycle calculations... |
|
I mixed up the intel feedstocks; the intel-compiler-repack at least has a spurious python dependency, which at least explains why the bot wants to build it for various pythons. We just need to add a |
|
numpy in a loop is real. here is what the graph says: (edit: printed the cycle from the wrong graph) The |
According to the current metadata perhaps, but it's all spurious IMO. With conda-forge/intel-compiler-repack-feedstock#47, we remove |
|
So the loop is gone, but cython isn't being marked as finished, despite the bot saying Pulling out the logs from the most recent bot run: |
|
The "archived or done" log message is incorrect. That message gets triggered by bad node attributes as well. I have fixed it in a PR. Let me check on the real issue. |
1 task
|
The real issue was the bot marking nodes as bad for rerender errors when it should not have been. Better testing would have caught this, but is hard. |
|
Thanks a lot for investigating and fixing this! 🙏 |
|
closing again since things are moving now. reopen if you see more issues! |
|
I'm reopening not because it's critical, more because I find it curious that some remnants of that loop still seem to be hanging around:
scipy should not depend on pynacl in any way |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There are open PRs in the 3.13 migration with 0(!) children, while feedstocks with >2000 children are awaiting PR. This seems quite suboptimal as a strategy, if we don't tackle the biggest bottlenecks the earliest.
Bottom of the table filtered to "In PR" currently looks like this:
The text was updated successfully, but these errors were encountered: