Deployment

NexT User Docs – Starting to Use — Deployment

Local Deployment

  1. Modify files locally.
  2. Localization testing: hexo clean && hexo g && hexo s.
  3. Deployment: hexo g -d.

Continuous Integration

  • Edit the file directly online, effective immediately
  • Automatic deployment, simultaneous deployment to multiple locations

Travis CI enables your team to test and ship your apps with confidence. It’s built for everyone and for projects and teams of all sizes, supporting over 20 different languages out of the box, including Javascript and Node.js, Ruby, PHP, Python, Mac/iOS, as well as Docker, while giving you full control over the build environment to customize it to your own needs.

There are two ways to obtain the necessary permissions for Travis CI. Deploy Key has the advantage of high security, while Access Token has the advantage of being more flexible.


This method applies to a warehouse with a private Submodule



  • Create an empty branch of source in the repository where the blog source is hosted.

  • Get the Access Token: Settings -> Developer settings -> Personal access token -> Generate new token. Set access rights according to the actual situation. It should be noted that the access token is only displayed once on this page, and it should be copied, otherwise it can only be regenerated.

  • Use github account to log in to Travis CI website. You can find the warehouses in the current github account, select the warehouses to be deployed, and then click setting. Fill in the personal access token generated by github and select the branch that the warehouse needs to be monitored by Travis.

Deploy key is a SSH key set in your repo to grant client read-only (as well as r/w, if you want) access to your repo. This method is suitable for most public blog repositories and there are no private sub-modules in the repositories.



  • Create an empty branch of source in the repository where the blog source is hosted.

  • Generate a ssh key


    1
    $ ssh-keygen -t rsa -b 4096 -C "{email}" -f ~/.ssh/deploy_key


  • Add the deployment public key in your repo, and delete it


    1
    $ rm -f deploy_key.pub


  • Use the Travis command to encrypt private key, and add it to git


    1
    2
    3
    4
    5
    $ gem install travis
    $ travis login
    $ travis encrypt deploy_key
    $ rm -f deploy_key
    $ git add deploy_key.enc



hexo/.travis.yml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
dist: trusty
sudo: required

addons:
 ssh_known_hosts:
   - github.com
   - git.coding.net
 apt:
   packages:
     - nasm

env:
 global:
   - TZ=Asia/Tokyo

language: node_js
node_js: node

branches:
 only:
   - source

git:
 depth: false
 submodules: false

cache:
 apt: true
 directories:
   - node_modules

before_install:
 # Git Config
 - sed -i 's/git@github.com:/https:\/\/github.com\//‘ .gitmodules
 - git config –global user.name “YOUR-GITHUB-NAME”
 - git config –global user.email “YOUR-EMAIL”

 # Restore last modified time
 - “git ls-files -z | while read -d ‘’ path; do touch -d \”$(git log -1 –format=\”@%ct\” \”$path\”)\” \”$path\”; done”

 # Submodules
 - git submodule update –recursive –remote –init

 # Deploy history
 - git clone –branch=master –single-branch YOUR-BLOG-REPO .deploy_git

 # SSH Setup
 - openssl aes-256-cbc -K $encrypted_693585a97b8c_key -iv $encrypted_693585a97b8c_iv -in deploy_key.enc -out deploy_key -d
 - eval “$(ssh-agent -s)”
 - chmod 600 ./deploy_key
 - ssh-add ./deploy_key

install: npm install

before_script:

script:
 - hexo clean
 - hexo g -d

GitLab offers a continuous integration service and pages service. If you add a .gitlab-ci.yml file to the root directory of your repository, and configure your GitLab project to use a Runner, then each commit or push, triggers your CI pipeline. The .gitlab-ci.yml file tells the GitLab runner what to do. By default it runs a pipeline with three stages: build, test, and deploy. You don’t need to use all three stages; stages with no jobs are simply ignored. And at the end, your websites will be published on GitLab Host automatically.

  1. Add .gitlab-ci.yml to the root directory of your repository, and configure it.
    hexo/.gitlab-ci.yml
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    image: node:8.11.2

    before_script:
      # Restore last modified time
      - “git ls-files -z | while read -d ‘’ path; do touch -d \”$(git log -1 –format=\”@%ct\” \”$path\”)\” \”$path\”; done”

    pages:
      stage: build
      cache:
        paths:
        - node_modules/
      script:
      - npm install hexo-cli -g
      - npm install
      # NEXT NPM installation
      - npm install hexo-symbols-count-time –save
      - git clone https://github.com/theme-next/theme-next-pace themes/next/source/lib/pace
      - hexo deploy
      artifacts:
        paths:
        - public
      only:
      - master
  2. Upload scaffolds, source, themes, .gitignor, .gitlab-ci.yml, _config.yml, and package.json to your Gitlab repository. 
    1
    2
    3
    4
    5
    6
    $ git init
    $ ssh -T git@gitlab.com
    $ git remote add origin YOUR-GITLAB-REPO-SSH-LINK
    $ git add .
    $ git commit -m "COMMIT MESSAGE"
    $ git push -u origin master

Now, your static website is available at https://yourname.gitlab.io/project that is similar to GitHub. More GitLab Pages config in here.

Of course, you also can pulish static website on GitHub Pages or others pages service. There are two ways to configure .gitlab-ci.yml:


  • Get the Access Token: Settings -> Developer settings -> Personal access token -> Generate new token. Set access rights according to the actual situation. It should be noted that the access token is only displayed once on this page, and it should be copied, otherwise it can only be regenerated.

  • Click SETTINGS-CI/CD → Variables in Gitlab, and defined access token as custom variable GITHUB_ACCESS_TOKEN. Or set USERNAME PASSWORD variable for coding repo.

  • Configure .gitlab-ci.yml: only add deploy stage at the end of this file
    hexo/.gitlab-ci.yml
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    github:
      stage: deploy
      script:
      - cd ./public
      - git init
      - git config –global user.name “YOUR-USER-NAME”
      - git config –global user.email “YOUR-EMAIL”
      - git add .
      - git commit -m “gitlab-auto-deploy”
      - git push –force –quiet –set-upstream https://$GITHUB_ACCESS_TOKEN@github.com/username/username.github.io.git master # replace github_access_token
      # - git config http.postBuffer 524288000
      # - git push –force –quiet –set-upstream https://$USERNAME:$PASSWORD@git.coding.net/username/reponame.git master # replace username & password, please escape the password
      only:
      - master


Deploy key is a SSH key set in your repo to grant client read-only (as well as r/w, if you want) access to your repo. This method is suitable for most public blog repositories and there are no private sub-modules in the repositories.



  • Generate a deploy key


    1
    $ ssh-keygen -t rsa -b 4096 -C "{email}" -f ~/.ssh/deploy_key


  • Click SETTINGS-CI/CD → Variables in Gitlab, copy the content of private key and defined it as custom variable DEPLOY_PRIVATE_KEY.



  • Configure .gitlab-ci.yml: only update script in before_script


    hexo/.gitlab-ci.yml
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    before_script:
      - export TZ=’Asia/Shanghai’
      - git config –global user.name “YOUR-USER-NAME”
      - git config –global user.email “YOUR-EMAIL”
      # Restore last modified time
      - “git ls-files -z | while read -d ‘’ path; do touch -d \”$(git log -1 –format=\”@%ct\” \”$path\”)\” \”$path\”; done”
      # Install ssh-agent if not already installed, it is required by Docker.
      # (change apt-get to yum if you use a CentOS-based image)
      - ‘which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )’
      # Run ssh-agent (inside the build environment)
      - eval $(ssh-agent -s)
      # Add the SSH key stored in SSH_PRIVATE_KEY variable to the agent store
      - ssh-add <(echo “$DEPLOY_PRIVATE_KEY”)
      # For Docker builds disable host key checking. Be aware that by adding that
      # you are suspectible to man-in-the-middle attacks.
      # WARNING: Use this only with the Docker executor, if you use it with shell
      # you will overwrite your user’s SSH config.
      - mkdir -p ~/.ssh
      - ‘[[ -f /.dockerenv ]] && echo -e “Host *\n\tStrictHostKeyChecking no\n\n” > ~/.ssh/config’
      # In order to properly check the server’s host key, assuming you created the
      # SSH_SERVER_HOSTKEYS variable previously, uncomment the following two lines
      # instead.
      # - mkdir -p ~/.ssh
      # - ‘[[ -f /.dockerenv ]] && echo “$SSH_SERVER_HOSTKEYS” > ~/.ssh/known_hosts’
      - apt-get update -qq && apt-get install -y -qq pandoc

    image: node:8.11.2

    pages:
      cache:
        paths:
        - node_modules/
      script:
      - npm install -g hexo-cli
      - npm install
      # NEXT NPM installation
      - npm install hexo-symbols-count-time –save
      - git clone https://github.com/theme-next/theme-next-pace themes/next/source/lib/pace
      - hexo deploy

      artifacts:
        paths:
          - public
      only:
        - master



Variables are not masked, and their values can be shown in the job logs if explicitly asked to do so. So make sure gitlab pipelines can only be viewed by yourself.