helm version check fails when rate-limited by github

[bacongobbler]

Given the following test from master:

><> go build -o bin/helm -ldflags "-X main.version=0.0.1" helm.go
><> for i in $(seq 1 100); do ./bin/helm update; done

You see a few of these (of course):

[WARN] A new version of Helm is available. You have 0.0.1. The latest is 0.1.0
---> Download version 0.1.0 here: https://github.com/deis/helm/releases/tag/0.1.0
---> Updating cache from https://github.com/deis/charts
---> Done

but a few runs down the line, it will eventually fail with the following:

[WARN] Skipped Helm version check: GET https://api.github.com/repos/deis/helm/releases/latest: 403 API rate limit exceeded for 70.67.241.2. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.) []
---> Updating cache from https://github.com/deis/charts
---> Done

I could see an issue where an entire company would run helm update and get rate limited. We should investigate a way to allow a helm user to add their own API credentials to the request (through config.yaml?) so they won't be rate limited when running helm update. We should also add advice to the helm update error to point the user in the right direction to attach their GitHub credentials.

[technosophos]

We should look at what Homebrew does.

[bacongobbler]

Homebrew uses an envvar called HOMEBREW_GITHUB_API_TOKEN as described in their man docs: https://github.com/Homebrew/homebrew/blob/2b5d884c80a80181e8f8dfa8550ae18363f60d5a/share/man/man1/brew.1#L595-L596. They use it for features like brew search

[technosophos]

We could do that, and we could provide a commandline switch on helm update, too. The cli package we're using makes it possible to do both at once (like $HELM_HOME).

[mattfarina]

I was thinking about this problem for another application. If you have a cache directory you can cache the last check. Only do it every so often (weekly?). Silently fail if there was an issue.

Does homebrew ever tell you when there's a new version?

I do know that Composer (the PHP package manager) phones home to their website rather than calling to Github. That allows them to avoid this issue.

[technosophos]

That would be a suitable alternative -- cache the data at helm.sh or somewhere, and then use that cached copy instead of hitting the GitHub API.