Fl0w3r

carpe diem

Deployment

NexT User Docs – Starting to Use — Deployment

Local Deployment

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

Continuous Integration

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

Netlify

Netlify is an all-in-one platform for automating modern web projects. Replace your hosting infrastructure, continuous integration, and deployment pipeline with a single workflow. Integrate dynamic functionality like serverless functions, user authentication, and form handling as your projects grow.

Perhaps you have already found that this website is deployed on Netlify. Checkout deploy.sh and netlify.toml in theme-next-docs repository for more information.

GitHub Actions

This Github Action automating Hexo deployment workflow, to allow you to leverage GitHub Actions to publish your Hexo site on Github Pages: hexo-action.

Travis CI

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

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

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

    $ rm -f deploy_key.pub

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

    $ gem install travis
    $ travis login
    $ travis encrypt deploy_key
    $ rm -f deploy_key
    $ git add deploy_key.enc
hexo/.travis.yml
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
 npm: true

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 CI

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
    image: node:lts

    before_script:
      # Set TimeZone, eg: Asia/Shanghai
      # - export TZ='Asia/Shanghai'
      # 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
      - npx hexo deploy
      artifacts:
        paths:
        - public
      only:
      - master

  2. Upload scaffolds, source, themes, .gitignore, .gitlab-ci.yml, _config.yml, and package.json to your Gitlab repository.

    $ 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 can also 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
    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

    $ 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
    before_script:
      # Set TimeZone, eg: Asia/Shanghai
      # - 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'

      # Install pandoc, eg: v1.19.2.1
      # - wget https://github.com/jgm/pandoc/releases/download/1.19.2.1/pandoc-1.19.2.1-1-amd64.deb
      # - dpkg -i ./pandoc-1.19.2.1-1-amd64.deb

    image: node:lts

    pages:
      cache:
        paths:
        - node_modules/
      script:
      - npm install
      - npx 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.