Document how to avoid rate limiting when using TravisCI

I think the solution is to once again stop using the custom drupal-* commands. I switched to trying out drupal-update after all of the vendor directory changes, but it looks like I have to go back to doing something like this:

before_script:
# snip
   - cd modules/composer_manager
   - php scripts/init.php
   - cd ../..
   - rm -rf vendor
   - rm composer.lock
   - composer install --prefer-source --no-interaction
# snip

Edit: spoke too soon, having trouble with the above. Tried composer update as well, but that just crashes composer. Ugh.

You need to run composer drupal-rebuild to rebuild the composer.json file.
After that you can run composer update with any argument you want.
(composer drupal-update is just a shortcut for composer drupal-rebuild + composer update)
That's what our GitHub modules do in their travis scripts.

My attempts are as follows:

1. Remove vendor directory (and composer.lock),

1.a. use composer update with --prefer-source
1.b. use composer install with --prefer-source

This results in composer throwing a RuntimeException: Could not scan for classes inside "vendor/symfony/http-foundation/Request.php" which does not appear to be a file nor a folder.

The solution to #1 is to use --prefer-dist, which is not an option because GitHub.

2. Remove vendor directory, use composer update with --prefer-source

This produces the same result as #1.

3. Remove composer.lock, use composer update with --prefer-source or composer install with --prefer-source

This results in composer trying to download dist for existing dependencies because that's it's default behavior. This won't work because of GitHub API limits.

4. Remove vendor directory (keep composer.lock), use composer install with --prefer-source

Obviously this won't work because Composer ignores composer.json in favor of composer.lock and my dependencies are not downloaded.

5. Things that I have yet to try

1. Don't use TravisCI or GitHub and pray that your users won't run into GitHub api limits when using Composer Manager from their development, CI and production environments.
2. Don't use Composer to download dependencies on TravisCI and come up with some hack solution of downloading and moving dependencies in place and dumping autoload. This isn't an option because then the CI or test environment does not match what a user would actually do.
3. Try deleting selective vendor directories and running through options 1-2 again to see if there is some magical combination to get composer, github, travis, and composer manager to work together.
4. Try completely managing drupal with composer with a composer.json. This also does not simulate what a user will do in all cases.

There are threads and threads about this in the Composer queue. We need to go through them and find an answer once and for all.

Yes. I am afraid of posting in that issue queue as it is a bit intimidating. :(

Another option I forgot about, manage drupal with composer completely. At the moment, drupalti or doing it manually will do checkouts of Drupal. This won't simulate what most users will do, but it could help.

I'll try that next.

EDIT: Now contains the final solution we iterated on.

webflo just helped me solve this problem for Commerce, by adding a GitHub OAuth token.

Steps:
1) Create a token at https://github.com/settings/tokens. Leave all scopes unchecked, you don't need them. This token has read-only to public data, so it's harmless.
2) Go to https://travis-ci.org/commerceguys/commerce/settings (replace commerceguys/commerce with your own repo)
and add a GITHUB_OAUTH_TOKEN env variable, containing the token you just created.
Make sure to set "Display value in build log" to ON, won't work otherwise.
3) Use the non-interactive (-n) mode in .travis-before-script.sh:

# Initialize composer_manager.
php modules/composer_manager/scripts/init.php
composer drupal-rebuild
composer update -n --verbose

4) In .travis.yml your before-install needs to have the git config line:

before_install:
  - composer self-update
  # Add the oauth token to prevent GitHub timeouts.
  - git config --global github.accesstoken $GITHUB_OAUTH_TOKEN
  - composer global require "lionsad/drupal_ti:dev-master"
  - drupal-ti before_install

The nice thing about this is that it has also allowed us to kill --prefer-source, we're back on dist, which is faster.

Hmm, I thought that adding tokens was only for TravisCI Pro, but if that's available then I think that would solve it by putting the token in an env. var.

Edit: s/key/token

Works for me.

https://travis-ci.org/mradcliffe/xero/builds/87564659

Next step, fix my PR for drupalti and switch to it.

Created https://www.drupal.org/node/2652054