Speed up package management on travis #12727
Conversation
/vendor should not be cached!
|
Tests need fixing, see for example #12726 Please merge. |
|
@tsteur Maybe this one too? |
Findus23
added
c: Performance
|
@Findus23 Any chance merging this? |
|
@szepeviktor Currently GDPR has highest priority, once that is finished we'll get back to other issues. Do you have any numbers how much this speeds up the build? I'd expected travis to already cache the repository so only the install should be skipped with this change. |
|
@Findus23 This caches composer packages. |
|
@szepeviktor Indeed. This shows that the install currently takes about 30s, so your change will speed it up by that amount (minus the time composer needs for updating), correct? |
|
@Findus23 Yes, bit-by-bit |
| @@ -138,6 +138,7 @@ after_success: | |||
| cache: | |||
| directories: | |||
| - "travis_phantomjs" | |||
| - $HOME/.composer/cache | |||
There was a problem hiding this comment.
wouldn't it be better to only cache $HOME/.composer/cache/files, as everything else might change to often, causing cache invalidations?
There was a problem hiding this comment.
Maybe you're right.
I contribute to many open-source projects - like WP-CLI - and we use this directory.
There was a problem hiding this comment.
Change frequency equals how many times we change the lock file.
There was a problem hiding this comment.
Guess our lock file isn't changed that frequently
There was a problem hiding this comment.
sgiehl
changed the title
Speed up package management on travis
/vendor should not be cached!