|
2 | 2 | title: Common Build Problems
|
3 | 3 | layout: en
|
4 | 4 | permalink: /user/common-build-problems/
|
| 5 | +redirect_from: |
| 6 | + - /user/build-timeouts/ |
5 | 7 | ---
|
6 | 8 |
|
7 | 9 | <div id="toc"></div>
|
@@ -196,10 +198,128 @@ This can be done with the follow addition to your `.travis.yml`:
|
196 | 198 | The above addition will reinstall the en\_US language pack, as well as the de\_DE
|
197 | 199 | language pack.
|
198 | 200 |
|
199 |
| -## Linux: apt fails to install package with 404 error. |
| 201 | +## Linux: apt fails to install package with 404 error |
200 | 202 |
|
201 | 203 | This is often caused by old package database and can be fixed by adding the following to `.travis.yml`:
|
202 | 204 |
|
203 | 205 | before_install:
|
204 | 206 | - sudo apt-get update
|
205 | 207 |
|
| 208 | + |
| 209 | +## Travis CI does not Preserve State Between Builds |
| 210 | + |
| 211 | +Travis CI uses virtual machine snapshotting to make sure no state is preserved between |
| 212 | +builds. If you modify CI environment by writing something to a data store, creating |
| 213 | +files or installing a package via apt, it does affect subsequent builds. |
| 214 | + |
| 215 | +## SSH is not working as expected |
| 216 | + |
| 217 | +Travis CI runs all commands over SSH in isolated virtual machines. Commands that |
| 218 | +modify SSH session state are "sticky" and persist throughout the build. For example, |
| 219 | +if you `cd` into a directory, all subsequent commands are run from that directory. |
| 220 | + |
| 221 | +## Git Submodules are not updated correctly |
| 222 | + |
| 223 | +Travis CI automatically initializes and updates submodules when there's a `.gitmodules` file in the root of the repository. |
| 224 | + |
| 225 | +To turn this off, set: |
| 226 | + |
| 227 | +```yml |
| 228 | +git: |
| 229 | + submodules: false |
| 230 | +``` |
| 231 | +
|
| 232 | +If your project requires specific options for your Git submodules which Travis CI |
| 233 | +does not support out of the box, turn off the automatic integration and use the |
| 234 | +`before_install` hook to initializes and update them. |
| 235 | + |
| 236 | +For example, to update nested submodules: |
| 237 | + |
| 238 | +```yml |
| 239 | +before_install: |
| 240 | + - git submodule update --init --recursive |
| 241 | +``` |
| 242 | + |
| 243 | +## Git cannot clone my Submodules |
| 244 | + |
| 245 | +If your project uses Git submodules, make sure you use public Git URLs. For example, on GitHub, instead of |
| 246 | + |
| 247 | + [email protected]:someuser/somelibrary.git |
| 248 | + |
| 249 | +use |
| 250 | + |
| 251 | + https://github.com/someuser/somelibrary.git |
| 252 | + |
| 253 | +Otherwise, Travis CI builders won't be able to clone your project because they don't have your private SSH key. |
| 254 | + |
| 255 | +## My builds are timing out |
| 256 | + |
| 257 | +Builds can unfortunately time out, either during installation of dependencies, or during the build itself, for instance because of a command that's taking a longer amount of time to run while not producing any output. |
| 258 | + |
| 259 | +Our builds have a global timeout and a timeout that's based on the output. If no output is received from a build for 10 minutes, it's assumed to have stalled for unknown reasons and is subsequently killed. |
| 260 | + |
| 261 | +At other times, installation of dependencies can timeout. Bundler and RubyGems are a relevant example. Network connectivity between our servers can sometimes affect connectivity to APT, Maven or other repositories. |
| 262 | + |
| 263 | +There are few ways to work around that. |
| 264 | + |
| 265 | +### Timeouts installing dependencies |
| 266 | + |
| 267 | +Bundler can time out downloading RubyGems or talking to the APIs at rubygems.org. In the same way, pip can be affected by network connectivity issues to the PyPi mirrors or CDN endpoints. |
| 268 | + |
| 269 | +Bundler itself now has a [built-in feature to retry](http://bundler.io/v1.5/bundle_install.html#retry) gem downloads or API calls when a network error or timeout occurs. |
| 270 | + |
| 271 | +You can add the `--retry` option with the number of retries you'd like to use. *Note: this may become a default in the future on Travis CI.* |
| 272 | + |
| 273 | +Here's what you can add to your .travis.yml: |
| 274 | + |
| 275 | + bundler_args: --retry 3 |
| 276 | + |
| 277 | +Beyond Bundler, you can wrap commands using the function `travis_retry` which checks the return code of a command, retrying it three times if the return code is non-zero. |
| 278 | + |
| 279 | + install: travis_retry bundle install |
| 280 | + |
| 281 | +Note that with Bundler, using one or the other should be sufficient to catch network timeouts affecting your build. Using the new `--retry` option has the benefit of giving you finer control about the total amount of retries. |
| 282 | + |
| 283 | +We recommend using `travis_retry` when you have commands that only install one or two RubyGems, for instance, or when they're timing out for other reasons. |
| 284 | + |
| 285 | +Most of our build-internal commands are wrapped with `travis_retry` to reduce the impact of temporary network hiccups. |
| 286 | + |
| 287 | +### Build times out because no output was received |
| 288 | + |
| 289 | +When a long running command or compile step regularly takes longer than 10 minutes without producing any output, you can adjust your build configuration to take that into consideration. |
| 290 | + |
| 291 | +The shell environment in our build system provides a function that helps to work around that, at least for longer than 10 minutes. |
| 292 | + |
| 293 | +If you have a command that doesn't produce output for more than 10 minutes, you can prefix it with `travis_wait`, a function that's exported by our build environment. |
| 294 | + |
| 295 | + install: travis_wait mvn install |
| 296 | + |
| 297 | +`travis_wait` writes a short line to the build log every minute for 20 minutes, extending the amount of time your command has to finish. |
| 298 | + |
| 299 | +We recommend careful use of `travis_wait`, as overusing it can extend your build time when there could be a deeper underlying issue. When in doubt, [file a ticket](https://github.com/travis-ci/travis-ci/issues/new) or [email us](mailto:[email protected]) first to see if something could be improved about this particular command first. |
| 300 | + |
| 301 | +## Troubleshooting Locally in a Docker Image |
| 302 | + |
| 303 | +If you're having trouble tracking down the exact problem in a build it often helps to run the build locally. To do this you need to be using our container based infrastructure (ie, have `sudo: false` in your `.travis.yml`), and to know which Docker image you are using on Travis CI. |
| 304 | + |
| 305 | +### Running a Container Based Docker Image Locally |
| 306 | + |
| 307 | +1. Download and install the Docker Engine: |
| 308 | + * [Windows](https://docs.docker.com/installation/windows) |
| 309 | + * [OS X](https://docs.docker.com/installation/mac) |
| 310 | + * [Ubuntu Linux](https://docs.docker.com/installation/ubuntulinux/) |
| 311 | +2. Select an image from [Quay.io](https://quay.io/organization/travisci). If you're not using a language-specific image pick `travis-ruby`. Open a terminal and start an interactive Docker session using the image URL: |
| 312 | + |
| 313 | + ```bash |
| 314 | + docker run -it quay.io/travisci/travis-ruby /bin/bash |
| 315 | + ``` |
| 316 | + |
| 317 | +3. Switch to the `travis` user: |
| 318 | + |
| 319 | + ```bash |
| 320 | + su - travis |
| 321 | + ``` |
| 322 | + |
| 323 | +3. Clone your git repository into the `/` folder of the image. |
| 324 | +4. Manually install any dependencies. |
| 325 | +5. Manually run your Travis CI build command. |
0 commit comments