Skip to content

fix(install): don't require the GitHub API when RAILWAY_VERSION is pinned - #1031

Open
krushiraj wants to merge 1 commit into
railwayapp:masterfrom
krushiraj:fix/install-sh-honor-pinned-railway-version
Open

fix(install): don't require the GitHub API when RAILWAY_VERSION is pinned#1031
krushiraj wants to merge 1 commit into
railwayapp:masterfrom
krushiraj:fix/install-sh-honor-pinned-railway-version

Conversation

@krushiraj

Copy link
Copy Markdown

Fixes #1030.

Problem

install.sh queries the GitHub API for the latest release at line 411 — unconditionally, and with a hard exit 1 on an empty result — before it checks whether the caller already pinned RAILWAY_VERSION (line 420), and before argument parsing (line 451).

DEFAULT_VERSION=$(curl -s https://api.github.com/repos/railwayapp/cli/releases/latest | grep -o ...)

if [ -z "$DEFAULT_VERSION" ]; then
  error "Failed to fetch latest version from GitHub"
  exit 1
fi

if [ -z "${RAILWAY_VERSION-}" ]; then
  RAILWAY_VERSION="$DEFAULT_VERSION"
fi

Three consequences when the API is rate-limited or unreachable:

  1. A pinned install fails. RAILWAY_VERSION=5.27.1 bash <(curl -fsSL railway.com/install.sh) errors out with Failed to fetch latest version from GitHub, even though DEFAULT_VERSION is discarded on the very next line. This is the reported failure — it bites CI pipelines that pin a version specifically to be insulated from rate limits.
  2. --help and --uninstall fail too. Both are handled well after line 411, so removing an already-installed binary requires a working network path to api.github.com.
  3. It always surfaces as this error rather than a curl failure: curl -s (no -f) exits 0 on a 403 and prints the rate-limit JSON body, so set -eu doesn't catch it — grep just finds no tag_name and DEFAULT_VERSION ends up empty.

Fix

Move the lookup into resolve_version(), return early when RAILWAY_VERSION is already set, and call it after argument parsing and after the uninstall/help blocks — immediately before the first use of $RAILWAY_VERSION. DEFAULT_VERSION had no other readers and is dropped. The unpinned failure path also now hints at pinning.

Verification

bash -n passes. Stubbing curl to return GitHub's 403 rate-limit body, on master vs. this branch:

Scenario master This PR
RAILWAY_VERSION=5.27.1 Failed to fetch latest version resolves .../download/v5.27.1/...
--help Failed to fetch latest version prints help ✅
--uninstall Failed to fetch latest version uninstalls ✅
no pin (regression check) error same error, plus a pinning hint ✅

Shell-only change; no Rust code is touched.

…nned

install.sh fetched the latest release from the GitHub API unconditionally at
the top of the script, and hard-failed on an empty response — before checking
whether the caller had already pinned RAILWAY_VERSION, and before argument
parsing. Three consequences:

- `RAILWAY_VERSION=x.y.z bash install.sh` failed with "Failed to fetch latest
  version from GitHub" on a rate-limited API, even though the version was
  explicitly pinned and the fetched value was never used.
- `--help` and `--uninstall` also failed, so removing an already-installed
  binary required a working network path to api.github.com.
- `curl -s` (no `-f`) exits 0 on a 403 and prints the rate-limit JSON body, so
  `set -eu` never caught it; the grep simply found no tag_name.

Move the lookup into resolve_version(), called after argument parsing and after
the uninstall/help paths, and return early when RAILWAY_VERSION is already set.
Pinning a version now makes an install independent of GitHub API rate limits,
which is the point of supporting the variable. Also suggest pinning in the
error message for the unpinned case.

Fixes railwayapp#1030
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

install.sh fails when GitHub API is unreachable, even if RAILWAY_VERSION is already set

1 participant