Remove Composer caching from Travis CI

[danepowell]

Composer 2 is so efficient that caching packages in Travis CI is more likely to slow down a build than to speed it up. See acquia/cli#405 for details.

We should evaluate whether any other kind of caching in Travis CI is having a similar effect.

This applies both to ORCA's internal tests as well as the example .travis.yml: https://github.com/acquia/orca/blob/develop/example/.travis.yml

[TravisCarden]

Wow, interesting... Of course we'll need to finish the Composer 2 conversion before we do any testing. I'll create an internal ticket for prioritization.

[wimleers]

Composer 2 compatibility is finished, so I think we should seriously consider this now 🤓

[wimleers]

Giving this a try at https://github.com/acquia/acquia_migrate/tree/wip-composer2-no-caching. So compare:

• no caching: https://travis-ci.com/github/acquia/acquia_migrate/builds/223868574
• caching: https://travis-ci.com/github/acquia/acquia_migrate/builds/223789923

I'm curious 🤓

[wimleers]

It's still running, but with the build mostly complete, it looks like for AMA this is a slight performance regression. Perhaps because AMA installs so many packages?

The test jobs in acquia/cli#405 all run very fast. I suspect that for those, it does more harm than good. But once you start doing integration testing and hence inevitably need to pull down drupal/core plus contrib modules, the caching is still a net positive.

P.S.: let's not forget TravisCI has an enormous variability in performance. You never know if it is an apples-to-apples comparison, unfortunately 😞

[danepowell]

@wimleers can you be more specific about the performance difference you're seeing? Comparing those two jobs, it looks like everything except the main script took nearly identical time. The main script did take longer without caching, but I wouldn't pin that on Composer: I don't see anywhere that it invokes Composer (correct me if I'm wrong), and the variance is still within 3%, which is much less than the margin of error for Travis CI.

It's totally possible that there's a performance regression, but I just don't see it here.

Specifically, I looked at these two jobs:

• https://travis-ci.com/github/acquia/acquia_migrate/jobs/500438005
• https://travis-ci.com/github/acquia/acquia_migrate/jobs/500263258

[wimleers]

https://travis-ci.com/github/acquia/acquia_migrate/builds/223868574 took 34 minutes for the 4th job.

https://travis-ci.com/github/acquia/acquia_migrate/builds/223789923 took 40 minutes for the 4th job.

But it looks like that 6 minute delta is 100% attributable to the test execution itself. I keep forgetting what a terrible high performance variance there is between TravisCI runs 😬 🤯

So: yes, I don't see a tangible performance difference here. But definitely also not an improvement. fixture_init.sh takes ~55 seconds for all AMA test jobs.