For most composer packages, the code is downloaded as an archive originating from github.com. They do enforce API rate limiting for unauthenticated users. With T106452, T248387 @bd808 went to generate a token:
I created https://github.com/composer-ratelimits-suck specifically for this purpose. I would be happy to share the account password with RelEng and/or SRE. There is nothing special about the account however, so it may be equally easy in the future to just spin up another GitHub account when needed.
This was done by e0982e0c4573e6dd32346d5e6499a881277f98d9 which changes the image entry point to set the composer config when the container starts:
if [ -n "${COMPOSER_GITHUB_OAUTHTOKEN}" ]; then
/srv/composer/vendor/bin/composer config -g github-oauth.github.com "${COMPOSER_GITHUB_OAUTHTOKEN}"
fiThe token is stored in the Jenkins credential store and injected to jobs.
I am not sure the entry point is always called and the Quibble images do not set the composer config.
Instead of having to invoke composer config, we could rely on the COMPOSER_AUTH environment variable. It is described at https://getcomposer.org/doc/03-cli.md#composer-auth :
The COMPOSER_AUTH var allows you to set up authentication as an environment variable. The contents of the variable should be a JSON formatted object containing http-basic, github-oauth, bitbucket-oauth, ... objects as needed, and following the spec from the config.
And authentication as a whole is documented at https://getcomposer.org/doc/articles/authentication-for-private-packages.md
We can set a credential that exposes COMPOSER_AUTH={"github-oauth":{"github.com":"<TOKEN>"}} and this way we no more need to ensure the entry point is called or to rely on composer config.