fix(check-update): avoid using self-hosted credentials for gitlab.com

Description

  • fix(check-update): avoid using self-hosted credentials for gitlab.com

When users have GITLAB_TOKEN set for their self-hosted GitLab instance and use glab as a Git credential helper, the update check would run after Git operations (like git push) and incorrectly attempt to use the self-hosted token to access gitlab.com's public releases API, resulting in authentication errors.

The new createUnauthenticatedClient function creates a client specifically for accessing public endpoints, preventing credential misuse across different GitLab instances.

Related Issues

Resolves #8054 (closed)

How has this been tested?

  1. Basic Functionality Test

Verify that the update check still works normally:

# Force an update check
GLAB_CHECK_UPDATE=true ./bin/glab check-update

Expected output:

  • Either "You are already using the latest version of glab!"
  • Or "A new version of glab has been released: vX.Y.Z -> vA.B.C"
  • No errors
  1. Test with Self-Hosted Credentials

Verify that self-hosted credentials don't interfere:

# Set fake self-hosted credentials and force update check
GITLAB_TOKEN=glpat-fake-self-hosted-token \
GITLAB_HOST=https://git.example.com \
GLAB_CHECK_UPDATE=true \
./bin/glab check-update

Expected output:

  • Should work without errors (no 401 Unauthorized)
  • Should show version information
  1. Verify No Token is Sent

Confirm that user credentials are not sent to gitlab.com:

# Run with HTTP debug logging
GLAB_DEBUG_HTTP=1 \
GITLAB_TOKEN=glpat-fake-token \
GLAB_CHECK_UPDATE=true \
./bin/glab check-update 2>&1 | grep -A 3 "Private-Token"

Expected output:

Private-Token: 
Accept-Encoding: gzip

Note the empty value after Private-Token: - this means no actual token is sent.

Merge request reports

Loading