You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the Cleanup & GitHub OAuth Token chapter of the ancistrano screencast, you advice to use a github token to avoid rate limiting issues for github downloads.
This advice is useless. The archive download endpoint is not covered by the github rate limit anymore since more than 1 year now (thanks to a discussion between the composer team and the github support, to decide whether Composer should follow bower and use internal endpoints used by the github UI instead of the API for downloads to workaround the rate limiting).
The only case where you still need to set a github token for your deployment is when using downloads from private repos (but this has nothing to do with rate limiting, it has to do with access).
Note that when using lots of VCS repositories in your project (instead of using Packagist or Satis), using a token on the server running composer update might still make sense (an update will need other API endpoints in such case to get the metadata). But an install from lock does not need anything else than the code archive.
The text was updated successfully, but these errors were encountered:
Yo Stof! This is awesome! I had no idea the rate limits were not hit anymore! I was already thinking that the token was less important anyways... as repeated deploys simply load from cache. We’re going to check into removing this!
In the
Cleanup & GitHub OAuth Token
chapter of the ancistrano screencast, you advice to use a github token to avoid rate limiting issues for github downloads.This advice is useless. The archive download endpoint is not covered by the github rate limit anymore since more than 1 year now (thanks to a discussion between the composer team and the github support, to decide whether Composer should follow bower and use internal endpoints used by the github UI instead of the API for downloads to workaround the rate limiting).
The only case where you still need to set a github token for your deployment is when using downloads from private repos (but this has nothing to do with rate limiting, it has to do with access).
Note that when using lots of VCS repositories in your project (instead of using Packagist or Satis), using a token on the server running
composer update
might still make sense (an update will need other API endpoints in such case to get the metadata). But an install from lock does not need anything else than the code archive.The text was updated successfully, but these errors were encountered: