search

Freeseer / freeseer

Designed for capturing presentations at conferences. Pre-fill a list of talks to record, record them, and upload them to YouTube with our YouTube Uploader.
http://freeseer.readthedocs.org
GNU General Public License v3.0
215 stars 110 forks source link

Speed up Travis CI builds #503

Open dideler opened 10 years ago

dideler commented 10 years ago

Our builds are starting to take kinda long. The last build I see at https://travis-ci.org/Freeseer/freeseer/ took 3 min 10 sec. It's tolerable for now, but we should keep an eye on it.

This article has some suggestions for speeding up builds: http://docs.travis-ci.com/user/speeding-up-the-build/

mtomwing commented 10 years ago

Maybe it's time to adopt a "fail faster" policy? For example, if the linter isn't successful it shouldn't bother running the unit tests. Same for unit tests and building the package.

zxiiro commented 10 years ago

I think it's worth running both linter and tester though so that you can see if both failed and fix both items at the same time.

mtomwing commented 10 years ago

At the same time, it's also trivial for contributors to run these themselves prior to comitting.

dideler commented 10 years ago

@mtomwing are you suggesting we remove the webhook builds in favour of running the tests locally?

mtomwing commented 10 years ago

@dideler now that would be a crazy idea. I'm just suggesting that contributors shouldn't rely on us testing their code during development.

dideler commented 10 years ago

Gotcha. In that case, I do like the fail fast approach. We should probably provide a git hook to make it easier for contributors to run tests locally (we can't enforce it, but we can advise them to use it).

dideler commented 10 years ago

Are you in favour of having the local tests show all errors or failing fast as well?

mtomwing commented 10 years ago

Yes if we can split the flake8 step into 2 parts:

If the linting fails, then we should fail right away as it usually indicates a critical syntax error.

zxiiro commented 10 years ago

Our builds are actually really fast. If you take the time to look at it the parts of the build that are slow are out of our control. I believe the longest parts of the build are all the apt-get install steps which depend on the internet.

mtomwing commented 10 years ago

True. I guess the next step might be to move the majority of the dependency installation steps to after flake8 is run?

zxiiro commented 10 years ago

Another option is to try out drone.io instead of travis. Going that route we could provide an exact VM image that we want to run and it would pull it and since it'll have all our dependencies preinstalled hopefully boots and runs quicker.