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 from 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 are not interchangeable, 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 and the organizations you belong to. At this point, select the repository you need Travis to build for you and toggle the switch next to the repository. Once a repository is activated, Travis will listen for all changes to that repository.
.travis.yml#
Travis requires a .travis.yml
file to be present in the root directory of the project. This is the configuration file that specifies Travis's behavior. The 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 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 needed
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, same as above
- 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 "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
through the GitHub API, which is 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 on the repository, so we only need to enable the repository-related permissions. The permissions should follow the principle of least privilege, enabling only what is necessary. After setting the permissions, click the generate button to complete the process and jump to the tokens list.
Now we need to copy the value of the Access Token we just generated. Note that once this page is refreshed, the token will no longer be displayed, and if you haven't remembered it, you will have to regenerate a new one.
Now that we have the Access Token and can operate the repository, where should this token be placed?
Definitely not in the code...
In fact, 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's display; otherwise, it would be equivalent to exposing the token.
Now we can use the $GITHUB_REPO_TOKEN
environment variable in our execution script to access the token~
Next is how to use it. Before deploying with Hexo, we should replace the original deployment repository address with the one 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 the address with the token that has permission to operate, and it will not leak or affect the original local configuration file.
Build Failure: Submodule Pull Failed#
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 found at #1, below are the key information extracted:
$ 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 the 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 to 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: The Most Accessible Illustrated Tutorial for Automatic Blog Publishing - @MichaelX
- Hexo+Github+Travis-ci Build Your Own Blog as a Programmer - @baiyangliu