entireio / entireio/cli

Install script hides GitHub API authentication and rate-limit errors

Open
#2,318 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug
Dominant language
Go
Stars
5.1k
Forks
475
Avg merge
1d 11h
Merged PRs (30d)
178

Description

What happened?

The install script reports every failure while fetching release metadata as an internet connectivity problem:

Failed to fetch latest version from GitHub. Please check your internet connection.

This also happens when GitHub returns an HTTP error, such as 401 for an
invalid GITHUB_TOKEN or 403/429 for rate limiting.

GITHUB_TOKEN=invalid ./scripts/install.sh

The request fails, but curl's diagnostic is discarded by:

curl "${curl_opts[@]}" "$url" 2>/dev/null
Steps to reproduce
  1. Run the script with an invalid token.
curl -fsSL https://entire.io/install.sh | GITHUB_TOKEN=invalid bash

You get the following:

==> Installing Entire CLI...
==> Detected platform: linux/amd64
==> Fetching latest stable version...
Error: Failed to fetch latest version from GitHub. Please check your internet connection.

The report is misleading. GitHub was indeed reachable, as the following example demonstrates, but that's not clear either because the script discards the HTTP errors GitHub returns.

  1. Reach GitHub directly to confirm.
GITHUB_REPO=entireio/cli curl https://api.github.com/repos/${GITHUB_REPO}/releases/latest

If you can reach GitHub, you get a response. The following was mine at the time.

{"message":"API rate limit exceeded for 195.242.214.166. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)","documentation_url":"https://docs.github.com/rest/overview/resources-in-the-rest-api#rate-limiting"}
  1. It does work with GITHUB_TOKEN unset.:
env -u GITHUB_TOKEN ./scripts/install.sh
==> Installing Entire CLI...
==> Detected platform: linux/amd64
==> Fetching latest stable version...
==> Installing version: 0.10.6
==> Downloading entire_linux_amd64.tar.gz...
==> Downloading checksums...
==> Verifying checksum...
==> Checksum verified
==> Extracting...
==> Installing to /home/theolujay/.local/bin...
==> Directory ready
==> Entire CLI installed to /home/theolujay/.local/bin/entire
==> Running post-install actions...
✓ Shell completion already configured in /home/theolujay/.bashrc
Entire CLI version

N/A

OS and architecture

Ubuntu 26.04 x86_64

Agent

N/A

Terminal

No response

Logs / debug output

Additional context
Proposed change

Capture curl's HTTP status and transport error separately, and provide actionable messages for:

  • invalid GITHUB_TOKEN (401)
  • rate limiting (403/429)
  • GitHub service failures (5xx)
  • DNS, TLS, timeout, and other curl transport failures
  • successful responses that don't contain a release tag

The token would never be printed.

I'd be happy to submit a PR for this change.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in scripts/install.sh at the curl invocation that redirects diagnostics to /dev/null, and reproduce the request with an invalid GITHUB_TOKEN or a rate-limited response. Separate HTTP status handling from curl transport failures and verify that messages distinguish 401, 403/429, 5xx, transport errors, and successful responses without a release tag while never printing the token.

Written by the indexing model from the issue text.

Assessment

Tech stack
bash, github, shell
Domain
api, cli, networking
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
76/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.