Hexo Workflow Automation 2

Posted on In , ,

Introduction

It has been a year since the previous post on Hexo workflow automation. Although I have not written many posts during this period, I remained unsatisfied with the existing workflow. Aiming to implement i18n, I made significant modifications to the source code repository and wrote new scripts. Additionally, I migrated the blog from GitHub Pages to Netlify. This post will cover the implementation process of these changes.

Refactoring the Source Repository

Hexo has very poor native support for i18n, making it unsuitable for direct use. If you want to add a new language, you can follow the method described in this article, which involves creating a new source repository and adding some JS code. Using this approach resulted in me having four GitHub repositories: a Chinese blog source repository, a Chinese blog repository (GitHub Pages), an English blog source repository, and an English blog repository (GitHub Pages). Maintaining multiple source repositories led to a lot of duplication and version management complexity. In reality, we can use a single source repository to manage blog sources for multiple languages (by creating subfolders like cn, en, etc., in the root directory, each being a Node.js project). Since Hexo is an SSG (Static Site Generation) framework, we can manually merge the artifacts from multiple languages to form a final version for deployment.

The build code from the previous post already exists. Readers only need to write a script to copy and paste the artifacts from the multiple languages, which won't be elaborated on here.

Migrating to Netlify

GitHub Pages is based on GitHub repositories, but using a Git repository to store artifacts is not a good practice. On one hand, incorrect use of Git wastes storage space. On the other hand, others might find an artifact repository confusing, given that GitHub is primarily a platform for source code. One of the biggest advantages of using GitHub Pages is that it's free. However, since many other sites also offer free hosting, why not migrate to one of them? Netlify is one such platform. As Netlify is very well-known, it won't be introduced in detail here.

Assuming the final artifact is located in the dist directory, we can use the Netlify CLI in GitHub Actions for deployment:

1
2
3
4
5
- name: Deploy
  env:
    NETLIFY_AUTH_TOKEN: ${{ secrets.NETLIFY_AUTH_TOKEN }}
    NETLIFY_SITE_ID: ${{ secrets.NETLIFY_SITE_ID }}
  run: npx netlify deploy --prod --no-build --dir=./dist
  • NETLIFY_SITE_ID: The Project ID (Site ID) found in Project configuration | General | Project information.
  • NETLIFY_AUTH_TOKEN: Apply for one in User settings | Applications | OAuth | Personal access tokens. This PAT has no scope settings; possessing a token grants full control over the entire account, which feels somewhat insecure.

Additionally, Netlify allows users to create a netlify.toml configuration file in the root directory to configure builds, redirects, headers, etc. I primarily used the 404 redirect functionality. This feature is enabled automatically in GitHub Pages but requires manual configuration in Netlify.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
[[redirects]]
from = "/cn/*"
to = "/cn/404"
status = 404

[[redirects]]
from = "/en/*"
to = "/en/404"
status = 404

[[redirects]]
from = "/*"
to = "/index.html"
status = 404
  • Rule interpretation: The Netlify server will only redirect to /cn/404 when the response code is 404 and the accessed path matches /cn/*. Normal visits are unaffected.

Dependabot

Over the past year, I have added Dependabot to many projects and had a good experience with it, so I also introduced Dependabot to this blog's source repository.

1
2
3
4
5
6
7
8
9
10
11
12
13
version: 2
updates:
  - package-ecosystem: "npm"
    directories: 
      - "/cn"
      - "/en"
    schedule:
      interval: "weekly"

  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"
  • The blog source repository has multiple subprojects, all of which need to be specified in the directories field.
  • Dependabot can also manage the versions of various actions used in GitHub Actions workflows.

Dependabot primarily serves the purpose of regularly checking for new versions. The most time-consuming part is actually reading the release notes for new versions and deciding whether to upgrade.

References