2.21.0 CLI Zip URL Broken

[giantramen]

During the codegen phase I am getting this error:
"Checking if CLI needs to be downloaded...
Downloading zip file with the CLI...
curl: (22) The requested URL returned error: 500 Server Error"

It was working yesterday so something must have changed on the server side

https://github.com/apollographql/apollo-ios/blob/f29d5108a7eead3c2423556c874b7e51785c831d/scripts/run-bundled-codegen.sh

For the others running into this problem, you can temporarily downgrade your Apollo to 0.17.0 and it will work again while we wait for a solution.

[designatednerd]

@giantramen How long has it been unavailable? We have seen hiccups in the Circle service from time to time but in the past they've always resolved after about 20-40 minutes.

[giantramen]

@designatednerd ~50 minutes

[vinamelody]

oh i just get this too! watching this thread ... this is the broken link https://34622-65563448-gh.circle-artifacts.com/0/oclif-pack/apollo-v2.21.0/apollo-v2.21.0-darwin-x64.tar.gz

[torcelly]

+1 😭

[giantramen]

No longer getting an error, however, this is a really bad dev experience if we can't build whenever this URL stops working.

[designatednerd]

So it should only not build if you have either a) Never downloaded the CLI locally, b) Somehow deleted your local copy of the CLI, or c) Have an outdated CLI which is attempting to update. In any of those cases, you're correct, when the CLI link is having a sad (either because Circle (or whatever other server we use in the future) is having a blip or you're not connected to the internet), it won't build.

If you do have the correct version of the CLI downloaded, then the script should not hit the branch of logic which contains the download link at all - You would be able to build from your local copy, which is what you do about 99.9% of the time.

The other option would be to include the raw binary zips with the repo. At 21MB each, that doesn't seem like a ton, but even with the couple versions that went through version control before we switched to a download link, the repo is already pretty bloated.

I'll talk to my team after the first of the year about getting this moved off of Circle's infrastructure to something more stable like a static AWS bucket, though.

[giantramen]

Moving to AWS sounds like a good solution.

Thanks for the quick response, and for all the work you do to update this project.

[jayasme]

Sadly in some part of the world AWS usually broken for access, could you please move the ZIP file to a global CDN? Or support a local solution. Thanks!

[designatednerd]

@jayasme Hasn't been moved yet - I'll make sure to check this out when we do make the move though!

[abernix]

@jayasme Are you willing to suggest what would be an ideal global CDN or what geographic boundaries are affected? AWS does operate CloudFront — which is a global CDN as far as a I'm aware — including options for mainland China.

To be honest though, we'd been considering Google Cloud CDN for other infrastructure already, so more curious about that in terms of what you're referring to / trying to overcome.

[rsaunders100]

Anyone who is having rouble with this, try running:

puma-dev -uninstall -d dev

Or lookout for other things that might be mapping .dev domains