Conversation
|
Hmmmm. Why is it trying to clone from GitHub? We're using the Pkg server, right? (I know we are using the Git registry, but even when using the Git registry, Pkg should still try to download the packages from the Pkg server first, before trying GitHub, right?) |
|
Also, even if we clone all the packages as Git repos, it still shouldn't take 27 minutes.... so I think something else (or multiple somethings) is going on here. |
DilumAluthge
left a comment
There was a problem hiding this comment.
This is fine, but I would like us to figure out the underlying issue (or issues).
|
But again, slow GitHub doesn't explain why the Pkg client isn't first trying to download the packages from the Pkg server. |
|
@giordano On line 44, can you change I tried to make a "suggestion", but GitHub won't let me, since that line isn't modified by the PR. |
|
At least there's finally an incident listed: https://www.githubstatus.com/incidents/gh0vvxtlj5v7 |
71df337 to
96209ba
Compare
|
As a confirmation this is working as intended, the instantiation step now takes 1 second, without output (because everything is already there): https://github.com/JuliaRegistries/General/runs/4642386103?check_suite_focus=true |
I'm seeing that also the instantiation step
General/.github/workflows/ci.yml
Line 59 in 2138ce3
often gets stuck when there are connections problems. See for example https://github.com/JuliaRegistries/General/runs/4641542758?check_suite_focus=true
The fact that this is trying to clone the Git repository instead of downloading the snapshot is another indication we're struggling with downloads from GitHub (and git clones are also slow). caching packages in addition to artifacts should help with this step.