之前的日子里，我的网站的自动部署经历了三个阶段。

第一阶段

服务器上运行一个 php while(1)和 git pull的脚本，使用nohup给放到后台，每次pull之后就sleep(10)，也就是每10秒pull一次。博客有变动的时候，最多10秒就会被服务器重新拉取。

缺点太多了，比如浪费资源。为了看拉取结果，我还在每次pull的时候把控制台输出的信息都保存在了日志里。最开始几天的日子里，还能cat log看看最近有没有冲突有没有拉取失败，一个月之后，再cat就能看到长达一分多钟的滚动字幕了。

时间再久一点，log文件就变得比代码都大了。这时候有智障就问了，为什么不把日志分开保存。每天一个日志文件不就好啦？

我干嘛不换个自动拉取程序呢……

第二阶段

第二阶段的开始，得益于我看到github有一个东西叫webhook。

和第一阶段一样的是，任何静态资源仍然都在本地生成，统一push到github上。服务器上有一个脚本，push成功后，使用github webhook向服务器脚本post一个消息，脚本接收到消息后前往对应的项目下执行git pull。

后来为了适应不同的项目类型，我在脚本里使用switch对repo名字进行匹配，执行不一样的脚本。

第二阶段的自动部署完成后，我写了一篇文章：让git push之后服务器能自动更新代码，顺便还把第一阶段的蠢逼设计也写了进去。这一部分的脚本代码被我放在了这个github repo里。

这一阶段的缺陷也很明显，它没法像runner那样有一个任务队列。如果两次push的间隔小于项目构建的过程，那么一定会导致一些不可预料的问题。所以就只能控制两次push的间隔，尽力避免因为缺陷而导致的问题。

关于这些问题，在github repo的readme里写得也很清楚

第三阶段

在工作中使用runner爽得不行，但是github上没有对应的工具，只能借助一些第三方的ci/cd工具，所以一直在用自己的傻狗伪装ci脚本。有一天我突然发现github更新了，多出了一个叫Github Actions的东西。于是我的第三阶段开始了。

Github Action的基本原理是，在启动action后生成一个虚拟容器，可以在这个虚拟容器下进行一系列的操作。

配置脚本之前，需要前往repo的配置下，设置私有变量ACTIONS_DEPLOY_KEY，这个变量是服务器的私钥。

新建一个github action workflow，用这样一个脚本

.github/workflows/main.yml

name: 就直接怼进去

on: [push]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - name: ssh
      env:
          ACTIONS_DEPLOY_KEY: ${{ secrets.ACTIONS_DEPLOY_KEY }}
          HOST: 39.***.***.207
          USER: root
          DEVELOP_SH_PATH: /root/hexobuild.sh
      run: |
        SSH_PATH="$HOME/.ssh"
        mkdir -p $SSH_PATH
        touch "$SSH_PATH/known_hosts"
        echo "$ACTIONS_DEPLOY_KEY" > "$SSH_PATH/id_rsa"
        chmod 700 "$SSH_PATH"
        chmod 600 "$SSH_PATH/known_hosts"
        chmod 600 "$SSH_PATH/id_rsa"
        eval $(ssh-agent)
        ssh-add "$SSH_PATH/id_rsa"
        ssh-keyscan -t rsa $HOST >> "$SSH_PATH/known_hosts"
        ssh -o StrictHostKeyChecking=no -i $SSH_PATH/id_rsa -A -tt $USER@$HOST sh $DEVELOP_SH_PATH

脚本大意是，把服务器私钥给容器，让容器通过ssh连接服务器，前往一个目录，执行一个脚本，这个脚本的内容是：

#!/bin/sh
cd /data/wwwroot/blog/tech
git pull
hexo clean
hexo g

这样不是常规的Github Action的使用方式。平常的用法应该是，在虚拟容器里先clone仓库文件，执行安装，执行生成静态文件，再把静态文件复制到服务器的对应目录。

管什么常规不常规的，好用就完事了。

从那之后，我再也不用每次push完博客再去ssh连接服务器看日志了。每次push完之后，我就安安静静等博客那边自己拉取最新再生成静态页。Actions页面里的记录是这样的：

第三阶段终于看上去高端一些了，Github Actions算是跟runner接近一些，可以抛弃笨比Webhook和我的蠢狗脚本。在用了一段时间后，Github Actions的问题又出现了……

Github最近好慢啊！

在服务器上clone根本不动，在本地挂了梯子也是龟速。有的网站被完全墙了，有的完全没墙，就github墙了一半，带死不死，难受死了。

所以这就是我最近好久好久没更新博客的理由。

既然更新了，说明我找到了新的方案。已经更新了搭建Gitlab+Runner，本来以为能进行完全自动化部署。结果服务器性能不够用，Gitlab给我开了30多个进程，直接卡死。下一篇更新用Jenkins+码云进行自动化部署。