这段文字主要讲述了作者对自动集成与部署（CI/CD）在云服务平台中的应用及其体验。以下是主要内容的总结：

1. 作者认为DevOps的重要一环是动集成与部署，特别是在Node.js领域，Vercel、Netlify和CloudFlare Pages已经整合了CI/CD，可以减少开发者在编写工作流Yaml文件上的时间，使他们更专注于编码本身。

2. 作者尝试使用CloudFlare Pages，但遇到一些问题。特别是当需要跨平台写作，并希望将博客内容上传到GitHub时，CloudFlare Pages并不能像Vercel和Netlify那样直接克隆仓库并构建。在处理同样的错误时，Netlify选择给出警告，而CloudFlare Pages则直接关闭了构建进程。

3. 作者提出了一个解决方案，使用GitHub Actions来生成静态文件。他提供了一个Yaml文件，这个文件能够在博客文件上传时自动编译。但是需要注意的是，如果GitHub Actions提交的静态文件触发了push操作，可能会导致问题。因此，他在Yaml文件中对push操作的条件进行了设置，只有在source文件夹有push操作（如新增文章，图片等）或者对主站配置进行更改时，GitHub Actions才会自动生成静态文件并提交。

4. 总的来说，作者认为这次的尝试是对CI/CD的一次小小的实践，尽管SaaS上的运行肯定会更复杂。他仍希望CloudFlare Pages能够改进其适配性。

序

(又来用上一篇文章的图了，逃)

自动集成与部署作为DevOps的重要一环，可以加快应用的发布，部署，等等……

仅nodejs家族领域，NextJS的爹Vercel，Hexo官方最喜欢的Netlify，以及后起之秀CloudFlare Pages都已经自动集成了CI/CD，方便用户少花点时间写那些又臭又长的Workflow Yaml，而专注于Code本身

正文

CloudFlare Pages（以下简称CF Pages）败给了前辈

当你真正有一个Cross-Platform写作需求且因此爱上了GitHub时，强大的欲望迫使你把Blog的一切上传到GitHub上。这么大一个公司，依傍在上面何尝不是个好选择（

恰好的，Vercel和Netlify可以直接clone repo并在自己的那套体系Build好然后交给CDN缓存。

前者通过识别框架，然后自动部署

后者则和CF pages一样，npm run build暴力解决

但，Netlify成功，CF Pages扔出了它的错误。

通过检查log，来看看两个平台如何处理

同样的Error

首先是Netlify

1
2
3

7:07:07 AM: [3/4] Linking dependencies...
7:07:07 AM: warning " > hexo-theme-fluid@1.9.7" has unmet peer dependency "nunjucks@^3.0.0".
7:07:08 AM: [4/4] Building fresh packages...

Netlify在根据yarn.lock来安装依赖时，发现了Peer Dependency nunjucks与其它项目依赖版本冲突。具体可查阅相关资料，此处不再赘述。

在这里，Netlify选择warn一下了事

反观CloudFlare

CloudFlare贴心的帮我们关掉了Build进程……

使用GitHub Actions辅助生成静态文件

上帝关掉了一扇门，但为你打开了一扇窗

如果你只是来抄作业的，可以将下面的Yaml复制了事

请记得：workflow必须对仓库有写权限，主题配置文件那一栏必须换成你的主题配置文件名

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

# This is a basic workflow to help you get started with Actions

name: CI

# Controls when the workflow will run
on:
  # Triggers the workflow on push or pull request events but only for the "main" branch
  push:
    branches: [ "main" ]
    paths: 
      - "source/*" # source file, includes pages and posts
      - "_config.yml" # hexo config
      - "_config.theme.yml" # theme config
  #pull_request:
  #  branches: [ "main" ]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v3

      - name: Setup Node.js env
        uses: actions/setup-node@v4.0.2
        with:
          node-version: 20.11.0
      # Runs a single command using the runners shell
      - name: Install Hexo
        run: sudo npm install hexo -g

      - name: Install dependencies
        run: npm install 

      - name: Build static files
        run: |
          hexo clean
          hexo g

      - name: Push to repo
        run: |
          git config --global user.email "bot@example.com"
          git config --global user.name "Auto Push Bot"
          git add public/
          git commit -am "Automatic generation by actions"
          git push

原理

我们当然希望GitHub Actions在博客全部文件Push时，自动编译。

但如果GitHub Actions提交上去，在push条件没有设置好时生成的静态文件仍然会触发。所以：

on加上path条件，使actions只有检查到source文件夹有push操作（如新增文章，图片，etc.）或者我们对主站配置进行更改时，GitHub Actions才会自动生成静态文件并提交

然后是配置nodejs环境。在GitHub Actions中，可以方便地引用官方给出的nodejs环境用法。这里尽量做到与本地环境一致。查询nodejs可以根据底下这样来操作：

1
2

$ node -v
v20.11.0

然后就是组合拳，安装依赖，生成静态文件，push。

总结

这次GitHub Actions可以算是小小的CI/CD实践，当然真正在SaaS上部署肯定更复杂。
还是祈求CloudFlare Pages适配吧。

这段文字是关于作者在尝试新的博客框架过程中遇到的一些问题和解决方案的记录。主要问题包括：

1.Wordpress的维护复杂度和对2C1G VPS的占用问题，因此作者尝试新的博客框架。
2.在使用Gitpod时，由于新建工作空间时需要绑定一个GitHub仓库，导致初始化IDE时克隆了仓库。解决方案是将.git文件夹移出，完成hexo init后再移回来。
3.Cloudflare Pages不支持构建Hexo，解决方案是通过GitHub Actions生成静态文件后，推送到仓库，再由Cloudflare Pages部署。
4.GitHub Actions不能推送，主要是写权限问题，git没有添加和设置身份，以及gitignore包含了public/，导致Git认为没有更改而没有推送。解决方案是更改这些设置。
5.由于只能使用Gitpod写50小时，但作者认为连同GitHub codespaces，这个时间已经足够他使用了。

序

由于Wordpress维护的复杂程度及对2C1G VPS致命占用，一次新的博客框架尝试开始了……
谨此记录。

困难

Not an empty folder

由于Gitpod在新建Workspace时强制要求绑定一个GitHub repository，导致初始化IDE时clone了repo。
但，众所周知，clone下来的repo包含git，这是Git用来记录更改和提交的folder，而VSCode是不显示此文件夹。

Solution：move .git在文件夹以外，hexo init完再move回来

Cloudflare Pages不支持构建Hexo

Cloudflare的Pages甚是慷慨，毕竟下面的条件怎么也不像一个亏损多年的公司干出来的事情

无限请求数
强大的cdn
我是CloudFlare的狗！

But，CloudFlare也是不支持Hexo，兴许是人家故意屏蔽博客（不过也不像啊）

Solution：GitHub Actions生成静态文件后，push到仓库，CloudFlare Pages再部署。

但由于文章Push到GitHub会被CloudFlare触发Triggers，故这不太像是一个好主意

GitHub Actions不能Push

1是写权限没给Workflow

2是git 不add不设置身份

3是gitignore居然包括了public/导致Git认为无更改从而没有Push

这个错误如果不是上面的Buff叠的压根没有发现

Solution：上面这些Buff否定改成肯定即可。

Billing

只能写50hrs的Gitpod。

不过Gitpod+GitHub codespaces能写很久了。

我又不是职业作家，要不到720hrs（逃）