Frequent timeouts with composer

[markguinn]

We've been having problems with our CI configuration for ss-shop being fragile and it looks like silverstripe-framework is having similar problems. These are not legitimate test failures but composer timeouts. I'm seeing two primary failures:

It could just be a temporary problem with Travis's infrastructure, but I wanted to flag it up anyway. I wonder if it would be possible to utilize Travis's dependency caching (http://docs.travis-ci.com/user/caching/) or find some other way to avoid doing a full Silverstripe install every time?

[markguinn]

This was fixed for me by adding sudo: false (which opts in to the new Docker-based infrastructure) to .travis.yml. Tests seem to be running much faster. I'm not sure if it's the new infrastructure or if they fixed whatever other problem was occuring.

[tractorcow]

I'm definitely noticing lots of timeouts with composer. Very annoying. =(

[markguinn]

I've tried the sudo: false thing on several other projects now and it consistently solves this problem as well as speeding up tests considerably. I'm happy to close this issue as that workaround doesn't relate directly to this module. I wonder if it would be good to mention that in the documentation for this module?

[tractorcow]

Let's test it out on framework, perhaps on a dev branch? I'm happy to leave this issue open here as a placeholder, since it's going to relate to all modules using travis-support.

[dhensby]

I think this issue is broken down into 2:

1. Requests to get composer.org timing out; and
2. Travis builds stalling

The first can be resolved with composer self-update || true to prevent the build falling (the self update is completely optional and this allows it to fail)

The second appears to be more of a Travis infrastructure problem, which has called down this week

[markguinn]

I think there's also a "travis_retry" command (though I've never tried it myself - http://docs.travis-ci.com/user/build-timeouts/) so you could do: travis_retry composer self-update

[dhensby]

@markguinn ultimately composer self-update is completely optional and really not required. If we retry rather than allow a graceful failure, then some more permanent issue with that command will still fail after 3 attempts and kill a build unnecessarily.

It doesn't appear travis_retry will help with builds that stop responding.

[tractorcow]

I got composer caching working over on https://github.com/silverstripe/silverstripe-framework/pull/4365 if anyone wants to have a look. :D

[dhensby]

I think we've provided about as much resilience as we can to the builds now. Anything else we have to blame on Travis :P

[tractorcow]

We fixed the timeout, but it raised a new issue which I've logged at https://github.com/silverstripe-labs/silverstripe-travis-support/issues/18

[tractorcow]

The prior fix has been removed; This is now unfixed again. :)

[dhensby]

I'm not seeing these errors anymore?

[markguinn]

Yes, I've not had any more problems with any of the modules I work on after adding sudo: false. Those modules are nowhere near as complex as framework or cms though.

[tractorcow]

Maybe no further action is necessary then.

[dhensby]

That is my view - I'd close this if I had the perms ;)

[markguinn]

I agree.

[tractorcow]

:D