-
Notifications
You must be signed in to change notification settings - Fork 394
Speed up builds by conditionally "returning early"? #1159
Comments
Sounds like a great idea! |
One quick note—for things like docs changes et all, you can add See: https://docs.travis-ci.com/user/customizing-the-build#Skipping-a-build |
@TravisCarden does using |
@grasmash, I think it's a good tool to have at our disposal, but I don't think it renders the feature suggestion less valuable. I won't be encouraging my developers to selectively bypass testing because I think that invites accidents and abuse. But an agreed-upon, deterministic rule for when tests can be safely bypassed is different. "Doesn't require incidental judgment" is a good CI attribute. Given good defaults or a well-chosen project standard, people don't even have to know about it to benefit from it, either, which is also good. Honestly, I don't expect to have time to contribute the feature myself for a while, but I think it's a feature worth having, and therefore worth remembering. My two cents. 😃 |
Finding inspiration here: facebook/react#1768 |
Update: I realized today that if you cut a release from a commit with |
One of the biggest drawbacks to running builds against pull requests is the time it adds to changes that don't actually need to be tested, like documentation edits, for example. I wonder if we could introduce some kind of white list concept whereby we "return early" if only files matching a given path pattern are changed. For example, if a pull requests only contains changes to Markdown files, there's probably no need to run automated tests or even generate a new build artifact. On most teams, that would be an instant savings of 10-30 minutes. Seems like we could probably come up with some sensible defaults for a white list easily enough to make for pretty good savings by default for most projects.
The text was updated successfully, but these errors were encountered: