Open JDGrimes opened 9 years ago
Awesome! Yes, I'd love to see a PR for this. This would really help with private repos on Travis, where build time is a premium. /cc @shadyvb
Seeing as I'm watching this repo, a couple more suggestions in addition to @JDGrimes:
If you move to checking out the WordPress develop repo it includes everything needed for PHPUnit and WordPress tests, also checking out with Git it is significantly faster than what wp-dev-lib
is currently using here via WP-CLI's wget/svn checkouts.
No need for for the MYSQLi database layer any more.
Take a peek at bbPress' .travis.yml
file for some hints and jump starting a pull request ;)
https://bbpress.trac.wordpress.org/browser/trunk/.travis.yml
@ntwb thanks for the input!
For reference, here is what WP-CLI is doing: https://github.com/wp-cli/wp-cli/blob/master/templates/install-wp-tests.sh
Right, a git clone
with --depth=1
I suppose would be faster than an SVN checkout, or maybe just as fast, since it would only be making one request instead of downloading/checking out multiple SVN URLs.
Will you be opening a PR to improve that install-wp-tests.sh
template in WP-CLI itself? If the performance can be fixed it in WP-CLI directly, then there will be more benefit all around.
I was working on improving the build time for a plugin a while back, and I found that there is potential here for some significant improvements:
WP_VERSION=latest
.sudo: false
to the config file so that the new, faster, container-based infrastructure is used. It means you can't usesudo
though. (WordPress has also implemented this.)fast_finish: true
to thematrix
. This will notify you of a failure as soon as it happens, rather than waiting until the whole build is finished. Then, by running the codesniff pass first, you get notified almost instantaneously for codesniff errors.WP_MULTISITE=1
andWP_MULTISITE=0
both on on a single pass for each version of WordPress. This speeds things up because it takes long enough to download WordPress that parallelization of multisite on/off is futile.composer install
on the codesniff pass. I don't see any reason it would be needed, unless the project is using other codesniffing tools that they are installing with composer. And in that case, they can runcomposer install
themselves.I have implemented all of this for a plugin, and I'd be happy to submit a PR if you are interested.