Travis CI生命周期以及不同阶段运行失败会导致生么构建结果。

The Build Lifecycle

A build on Travis CI is made up of two steps:

1. install: install any dependencies required
2. script: run the build script

You can run custom commands before the installation step (before_install), and before (before_script) or after (after_script) the script step.

In a before_install step, you can install additional dependencies required by your project such as Ubuntu packages or custom services.

You can perform additional steps when your build succeeds or fails using the after_success (such as building documentation, or deploying to a custom server) or after_failure (such as uploading log files) options. In both after_failure and after_success, you can access the build result using the $TRAVIS_TEST_RESULT environment variable.

The complete build lifecycle, including three optional deployment steps and after checking out the git repository and changing to the repository directory, is:

1. OPTIONAL Install apt addons
2. OPTIONAL Install cache components
3. before_install
4. install
5. before_script
6. script
7. OPTIONAL before_cache (for cleaning up cache)
8. after_success or after_failure
9. OPTIONAL before_deploy
10. OPTIONAL deploy
11. OPTIONAL after_deploy
12. after_script

Breaking the Build

If any of the commands in the first four stages of the build lifecycle return a non-zero exit code, the build is broken:

• If before_install, install or before_script return a non-zero exit code, the build is errored and stops immediately.
• If script returns a non-zero exit code, the build is failed, but continues to run before being marked as failed.

The exit code of after_success, after_failure, after_script and subsequent stages do not affect the build result. However, if one of these stages times out, the build is marked as a failure.

You can run steps before a deploy by using the before_deploy phase. A non-zero exit code in this phase will mark the build as errored.

If there are any steps you’d like to run after the deployment, you can use the after_deploy phase.

Build Timeouts

It is very common for test suites or build scripts to hang. Travis CI has specific time limits for each job, and will stop the build and add an error message to the build log in the following situations:

• A job produces no log output for 10 minutes
• A job on travis-ci.org takes longer than 50 minutes
• A job on travis-ci.com takes longer than 120 minutes

Some common reasons why builds might hang:

• Waiting for keyboard input or other kind of human interaction
• Concurrency issues (deadlocks, livelocks and so on)
• Installation of native extensions that take very long time to compile

There is no timeout for a build; a build will run as long as all the jobs do as long as each job does not timeout.

Rows that are Allowed to Fail

You can define rows that are allowed to fail in the build matrix. Allowed failures are items in your build matrix that are allowed to fail without causing the entire build to fail. This lets you add in experimental and preparatory builds to test against versions or configurations that you are not ready to officially support.

Define allowed failures in the build matrix as key/value pairs:

matrix:
  allow_failures:
  - rvm: 1.9.3