What is Travis CI?#
Travis CI is an online, distributed continuous integration service in the field of software development, used to build and test code hosted on GitHub. The code for this software is also open source and can be downloaded on GitHub, although the developers currently do not recommend using it alone in closed-source projects.
It supports multiple programming languages, including Ruby, JavaScript, Java, Scala, PHP, Haskell, and Erlang. Many well-known open-source projects use it for build testing on every commit, such as Ruby on Rails, Ruby, and Node.js.
Currently, Travis CI has two sites that provide different services:
Version | Homepage | Features |
---|---|---|
Free Version | https://travis-ci.org/ | Provides free service for open-source projects |
Paid Version | https://travis-ci.com/ | Can deploy GitHub private repositories |
The two sites can only see their respective projects and cannot be used interchangeably, so choose as needed.
Preparation#
First, visit the official website travis-ci.org, click the login button in the upper right corner, and log in to Travis CI using your GitHub account.
Travis will list all your repositories on GitHub, as well as the organizations you belong to. At this point, select the repository you need Travis to build for you and turn on the switch next to the repository. Once a repository is activated, Travis will listen for all changes to that repository.
.travis.yml#
Travis requires that there must be a .travis.yml
file in the root directory of the project. This is the configuration file that specifies the behavior of Travis. This file must be saved in the GitHub repository, and once there is a new commit in the code repository, Travis will look for this file and execute the commands inside it.
.travis.yml
:
language: node_js # Specify the language environment
node_js: '8.9.3' # Specify the NodeJS version
cache: npm # Specify the npm caching scheme, will cache $HOME/.npm or node_modules folder
dist: trusty # Specify the system version, trusty refers to the name of the Ubuntu 14.04 release
sudo: required # Whether sudo permissions are required
branches: # Specify the branches to build
only: # only means to build only the following branches
- source
before_install: # Execute before the install phase
- npm install -g hexo-cli # Globally install Hexo command line tool
install: # Commands to run during the installation phase, one per line, similar to before_install
- npm install # Install dependencies in package.json
script: # Commands to run during the build phase, one per line, similar to before_script, after_script
- hexo clean
- hexo generate # Hexo regular commands, execute clean and generate
after_success: # Execute when the script phase is successful, will not execute if the build fails, others are the same
- git config --local user.name "travis-ci"
- git config --local user.email "[email protected]"
- sed -i'' "[email protected]:~https://${GITHUB_REPO_TOKEN}@github.com/~" _config.yml
- hexo deploy > /dev/null # Deploy the blog using Hexo's deploy command
For more usage tips, please refer to the "Continuous Integration Service Travis CI Tutorial".
Now, there is another question: our goal is to automatically deploy to GitHub Pages using the hexo deploy
command, but Hexo is configured to use Git push for deployment (supported by the hexo-deployer-git
plugin). So how does Travis CI have permission to operate my GitHub repository?
GitHub Access Token#
The following content is excerpted from "Using Travis to Automatically Build Hexo to GitHub"
GitHub allows you to add a "Personal access token" through the settings page. Using the Access Token will have permission to access your repository via https
using the GitHub API, which is exactly what we need.
Now let's add a token. First, go to your GitHub settings page, click Personal access tokens
→ Generate new token
button to create a new token.
In the permission settings, we only need to operate the repository, so we only need to enable the repository-related permissions. The permissions should follow the principle of least privilege, allowing as few as possible. After setting the permissions, click the generate button to complete the generation and jump to the tokens list.
Now we need to copy the value of the Access Token just generated. Note that once this page is refreshed, the token will no longer be displayed, and if you didn't remember it, you can only regenerate a new one.
Now that we have the Access Token and can operate the repository, where should this token be placed?
Certainly not in the code...
Actually, the Travis CI project settings interface provides a way to set environment variables, and we should place the token there.
Return to our Travis CI blog project settings page, add an environment variable named GITHUB_REPO_TOKEN
to store our token, and remember to set Display value in build log
to OFF
to hide the variable, otherwise it would be equivalent to exposing the token.
Now we can use the $GITHUB_REPO_TOKEN
environment variable to access the token in our execution script!
Then, how to use it? Before deploying with Hexo, we should replace the original deployment repository address with the address containing the Access Token
, so we add a command before the hexo deploy
command in .travis.yml
:
sed -i'' "[email protected]:~https://${GITHUB_REPO_TOKEN}@github.com/~" _config.yml
This way, during execution, this command will automatically replace it with the token address that has permission to operate, and it will not leak or affect the original local configuration file.
Build Failure: Submodule Pull Failure#
The third-party theme of this blog is managed using
git submodule
. You can refer to "Hexo Build Personal Blog #04 Theme Installation and Custom Styles"
Detailed build logs can be seen #1, here are the key pieces of information:
$ git submodule update --init --recursive
Submodule 'themes/skapp' ([email protected]:Mrminfive/hexo-theme-skapp.git) registered for path 'themes/skapp'
Cloning into '/home/travis/build/y0ngb1n/y0ngb1n.github.io/themes/skapp'...
Warning: Permanently added the RSA host key for IP address '192.30.253.113' to the list of known hosts.
Permission denied (publickey).
fatal: Could not read from remote repository.
Travis CI officially supports Git Submodules by default, and will pull the submodule repositories by default when pulling the repository, but this feature can be manually disabled.
Since the repository address used [email protected]
with SSH
protocol when using git submodule
, the pull failed. Here are two solutions:
- Adding to SSH Known Hosts - Official solution provided
- Manually modify the repository address configured in
.gitmodules
to change the repository link fromgit
protocol tohttps
protocol
I used solution 2, changing to https
protocol:
[submodule "themes/skapp"]
path = themes/skapp
url = https://github.com/Mrminfive/hexo-theme-skapp.git
After pushing the modification to GitHub, Travis CI will build, and at this point, you can see that #2 built successfully.
View Build Status in README#
We can add the Travis CI build status in the README
, making it easy to check the project's build status on Travis CI. — Embedding Status Images, Shields.io
References#
- Travis CI Tutorial - @Travis CI Docs
- Continuous Integration Service Travis CI Tutorial - @Ruan Yifeng
- Travis CI Continuous Integration GitHub Personal Blog - @Lu Jiahao
- Using Travis to Automatically Build Hexo to GitHub - @zthxxx
- Out-of-the-box, Hexo Blog's github+server automatic deployment - @Wu Jiang
- Automatically Deploy Hexo Blog with Travis CI - @Karl
- Using Travis CI to Automatically Deploy Hexo Blog - @wshunli
- Hexo Meets Travis-CI: Possibly the Most Understandable Illustrated Guide to Automatically Publishing Blogs - @MichaelX
- Hexo+Github+Travis-ci Build Your Own Blog - @baiyangliu