Travis gem is really slow due to config file size explosion

[Ezku]

I've been wondering why the Travis gem is really slow to start up and run any commands. Today it stopped running anything at all and yields only timeouts like this, after multi-minute running times:

An error occurred running `travis help`:
    RuntimeError: expected SCALAR, SEQUENCE-START, MAPPING-START, or ALIAS
        from /Users/ezku/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/psych/visitors/emitter.rb:31:in `scalar'
        from /Users/ezku/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/psych/visitors/emitter.rb:31:in `visit_Psych_Nodes_Scalar'
        from /Users/ezku/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/psych/visitors/visitor.rb:15:in `visit'
        from /Users/ezku/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/psych/visitors/visitor.rb:5:in `accept'

On a hunch, I checked out the contents of $HOME/.travis. Here's what I found.

λ  ~  ls -la .travis
total 4066880
drwx------   5 ezku  staff         170 Sep 21 17:23 .
drwxr-xr-x+ 84 ezku  staff        2856 Sep 21 17:47 ..
-rw-------   1 ezku  staff  2082147304 Sep 21 12:03 config.yml
-rw-r--r--   1 ezku  staff        3805 Sep 21 17:23 error.log
-rw-r--r--   1 ezku  staff       88230 Aug 13 15:53 travis.sh

Checking tail -n 1000 .travis/config.yml, it seems like most of that is taken up by an encrypted block of data. After a cleanup and a plain travis login --pro, the size is 192 and I'm able to run commands without timing out.

I'm on OS X 10.10.5.

[rkh]

Very strange. I'm not sure how that much data ended up in there, or what encrypted data that might have been.

[Ezku]

Here's what I had in the file: https://gist.github.com/Ezku/146eafeb2149b124b9eb

[jamestalmage]

:+1:

$ rm ~/.travis/config.yml
$ travis login

Performance vastly improved! (30 seconds minimum per command down to <1).

[reem]

I also experienced this (my config.yml became huuuuge and all my commands became very slow). Deleting my config.yml vastly improved performance.

[BanzaiMan]

It would be imperative to understand what sequence of commands would lead to this situation. Somehow we end up dumping a HighLine::String object, so it must be some sort of user input, but it is hard to guess from here.