Continuous Integration 02 Travis CI

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:

  1. Code is Github repository
  2. The project has the code can be run
  3. 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.ymlfile, 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: installphase (installation dependent) and scriptphase (running script)

install

installField 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 command1failed, the entire building will be stopped, no further downward.

If not installed, skip the installation phase, direct to true:

install: true

script

scriptField 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

scriptAnd installnot the same, if command1fails, command2will continue, but the entire state of the construction phase of a failure.

If command2only in command1order to perform successfully, you need to write

script: command1 && command2

Node project

Node project installand scripthas a default script, can be omitted:

  • installDefaultsnpm install
  • scriptDefaultsnpm test

See more configuration official documents .

deploy

scriptAfter 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.ymlthe 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, installPerformed before stage
  • before_script, scriptPerformed before stage
  • after_failure, scriptAfter the failure of the implementation phase
  • after_success, scriptAfter the successful execution stage
  • before_deploy, depolyPerformed before step
  • after_depoly, depolyPerform the following steps
  • after_script, scriptPerformed after stage

The life cycle

Complete life cycle:

  1. before_install
  2. install
  3. before_script
  4. script
  5. aftersuccess/afterfailure
  6. before_deploy(Optional)
  7. deploy(Optional)
  8. after_deploy(Optional)
  9. 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 execution
  • errored, before_install, install, before_scriptThere are non-zero exit code will stop running immediately
  • failed, scriptThere is a nonzero status code will continue

skills

Environment Variables

.travis.ymlThe envfield 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.ymlconfiguration 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_tokenthe need to provide personal Github credentials generated by reference Github documentation

Here personal credentials need to check public_repoor repo.

After generating the certificate, in order to prevent disclosure of personal credentials, not directly .travis.ymlfill 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_cleanupset 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/blogthe local directory of all repository pushed to duola8789/blogthe gh-pagesbranch, and I now want is the duola8789/blogrepository publicdirectory pushed to duola8789.github.io.gitthe masterbranch, so according to the document , the prompt .travis.ymlincrease 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.ymlthe 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.ymlthe 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.ymlreference 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, pushthe 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.

reference

Guess you like

Origin blog.csdn.net/duola8789/article/details/93855665