502/404 installing Rover

[maschwenk]

Description

The Rover install baked into the npm module (the devDep approach) is very unstable for us.

installing plugin 'supergraph-0' for 'rover supergraph compose'...
error: HTTP status server error (502 Bad Gateway) for url (https://rover.apollo.dev/tar/supergraph/x86_64-unknown-linux-gnu/latest-0)

We get that or

#20 92.57 .../node_modules/@apollo/rover postinstall: Error fetching release: Request failed with status code 404
#20 92.57 .../node_modules/@apollo/rover postinstall: Failed

So it seems to be either 404'ing or 502'ing intermittently. The devDep approach is convenient, but it'd be good to understand why this approach is so unstable for us.

Steps to reproduce

npm install/pnpm install with @apollo/rover in your devDeps

Expected result

It should install the rover binary

Actual result

It errors

Environment

Run rover info and paste the results here

Rover Info:
Version: 0.10.0
Install Location: /stuff/node_modules/.pnpm/binary-install@1.0.6_debug@3.2.7/node_modules/binary-install/node_modules/.bin/rover
OS: Mac OS 13.2.1 [64-bit]
Shell: /bin/zsh

[irontitan76]

Same issue over here—noticed it for our CI/CD pipeline. Is the tar file at the endpoint at which it's fetching the binary down, unstable, or the like?

[maschwenk]

~Yeah just noting that it feels weird that the devDep solution will fetch the latest at all times. I would think it should be pinned to whatever version was latest at the time the package version was cut...or something.~ Was looking at the wrong code, see below

[irontitan76]

It's failing on "postinstall": "node ./install.js", for Rover's internal package.json script for us, which subsequently performs a lookup/download for the binary using the following structure:

const url = `https://rover.apollo.dev/tar/${name}/${platform.RUST_TARGET}/v${version}`;

which is at @apollo/rover/binary.js#L105 and from what I can gather the name is rover and the version is 0.10.0 for us. As for the RUST_TARGET, still trying to gather that for our CI machines.

[irontitan76]

https://rover.apollo.dev/tar/rover/x86_64-unknown-linux-gnu/v0.10.0 is erroring.

[flex-tjon]

My suspicion is that this is caused by the ongoing Github packages outage, https://www.githubstatus.com/incidents/sn4m3hkqr4vz

[andrewhamon]

flow-bin is some prior art on how to bake binaries into an npm package without a postinstall that goes out to the internet.

[carldunham]

This is killing us! Are there more command-line options or env vars that need to be changed or added?

[irontitan76]

You can try your luck at installing different versions for rover. For my team, we upgraded from 0.10.0 to 0.12.1, tested it out, and were potentially just lucky at getting the binary to download.

[victoriris]

Any updates?

[nocive]

bump

[maschwenk]

What we've done to get around this is just replacing the logic with:

const { BINARY_NAME, RUST_TARGET } = getPlatform();

const url = `https://github.com/apollographql/rover/releases/download/v${version}/${BINARY_NAME}-v${version}-${RUST_TARGET}.tar.gz`;
const binary = new Binary(BINARY_NAME, url);

Apollo includes the binaries as part of their Releases. Github Releases are very stable from my experience. Support was added for overriding apollo.dev with APOLLO_ROVER_DOWNLOAD_HOST env var, but the way the urls is constructed for the Releases and apollo.dev are very different.

const download_host = process.env.npm_config_apollo_rover_download_host || process.env.APOLLO_ROVER_DOWNLOAD_HOST || 'https://rover.apollo.dev'
// the url for this binary is constructed from values in `package.json`
// https://rover.apollo.dev/tar/rover/x86_64-unknown-linux-gnu/v0.4.8
const url = `${download_host}/tar/${name}/${platform.RUST_TARGET}/v${version}`;