Travis CI is the largest market share of continuous integration tool, which is free for open source projects, but for private projects and companies the project for a fee.
Travis CI is a continuous integration service provided, it is bound project on Github, as long as there is a new diamante, will automatically crawl, and then provide a runtime environment, perform testing, build, and deploy to the server.
Preparation for Use
Travis CI supports only Github, does not support other code hosting projects, so the premise of using Travis CI is:
- Code is Github repository
- The project has the code can be run
- Included in the project to build or test scripts
After the above conditions are met, we need access to their official website , use Github account login Travis CI. After landing Travis CI will list all of the code repository on Github
Select the button to open, activate this warehouse, Travis will monitor all changes in this warehouse.
.traivs.yml
Travis requirements under the project, there must be a .travis.yml
file, and must be submitted to the code repository. This is a configuration file that specifies the behavior of Travis, is essential.
File is YAML format :
# 指定默认运行环境
language: node_js
## 指定 node 版本
node_js:
- "node"
# 指定执行的脚本
script: test.js
# 需要 sudo 权限
sudo: required
# 安装依赖之前执行
before_instasll: sudo pip install foo
Run Process
Travis running process consists of two phases: install
phase (installation dependent) and script
phase (running script)
install
install
Field is used to specify the installation script:
install: npm install
If you have multiple scripts can be written in the following form:
install:
- command1
- command2
If command1
failed, the entire building will be stopped, no further downward.
If not installed, skip the installation phase, direct to true
:
install: true
script
script
Field is used to specify build or test scripts
script: npm run test
If you have multiple scripts can be written in the following form:
script:
- command1
- command2
script
And install
not the same, if command1
fails, command2
will continue, but the entire state of the construction phase of a failure.
If command2
only in command1
order to perform successfully, you need to write
script: command1 && command2
Node project
Node project install
and script
has a default script, can be omitted:
install
Defaultsnpm install
script
Defaultsnpm test
See more configuration official documents .
deploy
script
After the stage, you can set notification step and deployment steps , they are not necessary.
Deployment script can be executed in script stage, you can also use the quick deployment capabilities Travis as dozens of common services provided.
Notice
In .travis.yml
the following configuration
notifications:
email:
recipients:
- [email protected]
slack:
on_success: never
on_failure: always
When the failure will send an email notification
Hook method
Travis provides a hook for these seven stages above:
before_install
,install
Performed before stagebefore_script
,script
Performed before stageafter_failure
,script
After the failure of the implementation phaseafter_success
,script
After the successful execution stagebefore_deploy
,depoly
Performed before stepafter_depoly
,depoly
Perform the following stepsafter_script
,script
Performed after stage
The life cycle
Complete life cycle:
before_install
install
before_script
script
aftersuccess
/afterfailure
before_deploy
(Optional)deploy
(Optional)after_deploy
(Optional)after_script
Operating status
Travis after each run, four states may return
passed
, Run successfully, exit code all steps are0
canceled
, The user cancels the executionerrored
,before_install
,install
,before_script
There are non-zero exit code will stop running immediatelyfailed
,script
There is a nonzero status code will continue
skills
Environment Variables
.travis.yml
The env
field can be defined environment variables.
env:
- DB=postgres
- SH=bash
- PACKAGE_VERSION="1.0.*"
Internal script you can use these variables, preceded by the use of $
the symbol
have some environment variables (such as passwords) can not with open, by Travis website, written in the setting of each item inside, Travis will be automatically added to the environment variables, such internal script can still use environment variables, but only administrators can see the value of the variable
Encrypted information
If you do not trust confidential information in plain text sites exist Travis, Travis can use the encryption provided. You can refer Nguyen teacher's presentation and official documents .
Deployment Github Pages
To deploy my Github Pages blog is an example, according to the official website of the document , .travis.yml
configuration is as follows:
deploy:
provider: pages
skip_cleanup: true
github_token: $GITHUB_TOKEN
keep_history: true
on:
branch: master
To be noted that:
(1) github_token
the need to provide personal Github credentials generated by reference Github documentation
Here personal credentials need to check public_repo
or repo
.
After generating the certificate, in order to prevent disclosure of personal credentials, not directly .travis.yml
fill in personal credentials, and you need to add the credentials way to set aside the amount of the corresponding item in the inside Travis CI
(2) The second point to note is that needs to be skip_cleanup
set true
, otherwise Travis CI will be generated during the build process delete all the files, may cause had wanted to upload file deletion
More configuration options reference [documentation] ( https://docs.travis-ci.com/user/deployment/pages/.
Later experiments about the configuration is complete, the newly added article, "Getting Started with 01 continuous integration."
The thought will be very smooth, the result of several attempts before Travis CI accordance with the above configuration push success, because my blog page source and is on two different warehouses, warehouse source https://github.com/duola8789/blog.git
, and warehouse page https://github.com/duola8789/duola8789.github.io.git
, so when the direct push push always fail, because it defaults to duola8789/blog
the local directory of all repository pushed to duola8789/blog
the gh-pages
branch, and I now want is the duola8789/blog
repository public
directory pushed to duola8789.github.io.git
the master
branch, so according to the document , the prompt .travis.yml
increase in the following configuration
deploy:
# 新增
repo: duola8789/duola8789.github.io
local_dir: public/
target_branch: master
The new warehouse specified in items to be pushed first page where the second term which indicates the local directory to push, push to modify the third branch. While _config.yml
the Hexo push configuration commented:
deploy:
type: git
# repo: https://[email protected]/duola8789/duola8789.github.io.git
branch: master
This amendment after the completion of a successful push:
In the Internet to find information, are not assisted by Travis CI configuration, but the use of a custom configuration, can also be successful, below this is a relatively simple one , it is also recommended (to _config.yml
the Hexo push configuration Notes out):
language: node_js
node_js: stable
cache:
directories:
- node_modules
before_install:
- git config --global user.name "zh"
- git config --global user.email "[email protected]"
- npm install -g hexo-cli
- export HEXO_DEPLOYER_REPO=https://[email protected]/duola8789/duola8789.github.io.git
script:
- npm run deploy
Sure enough, do not they try, are not convincing.
If you encounter a 403 error-free access to push, usually Github Token problems, if there is no correct setting environment variables, waving at no .travis.yml
reference to the right.
The original management blog, after the paper is done in two steps need to, first of all npm run deploy
, to regenerate the local, packing paper, will publish articles to https://github.com/duola8789/duola8789.github.io.git
, again commit
, push
the current source code, submit to https://github.com/duola8789/blog.git
. Now after configuration, the warehouse can be submitted directly to the source, the other Travis CI will help us.