提交代码到 github 后,更新自动同步到 gitee(码云),使用 github action 实现
背景
github 在国内访问慢,在某些情况下,为了让国内不会使用科技的人能看到代码仓库,每次更新后自动同步到 gitee, 但是 gitee 没有自带这个功能,原因嘛,有了自动同步大家都这么做的话,gitee岂不是成为 github 的镜像站了2333
所以需要我们自己实现,利用 github action 或者 travis ci 都可以,这里介绍 github action,很简单。
准备
创建仓库
在 gitee 注册用户创建一个仓库,创建的时候可以选择从其它仓库导入,也可以不选择,不影响,其它内容选择空。
如果选了导入, 可以看到,这里有一个手动同步按钮, 但是只能手动点击同步。
生成 key
在电脑中生成key:
ssh-keygen -t rsa -f key.txt
这会生成两个key,一个公钥key.txt.pub和 私钥key.txt
设置 key
公钥部署到 gitee
在 https://gitee.com/profile/sshkeys 添加一个新的公钥,即key.txt.pub里面的内容, 注意是公钥不是私钥
私钥部署到 github action 加密变量
到需要同步的仓库,点击设置,选择 serects, 添加一个加密键值, 取名叫 GITEE_SYNC_ACCESSS_KEY, 值则复制私钥文件key.txt里面的内容即可,注意是私钥,不是公钥。为了后面的不能修改直接使用,名字请一定是GITEE_SYNC_ACCESSS_KEY
这样就把这个密钥储存到这个变量里面,因为这个私钥很重要,不能泄露,所以存在这个变量中,然后我们在 action 里面使用, 就不会暴露到源码中了
添加 github action
在 github 上要同步的仓库里面点击action, 然后点击 set up a workflow yourself
然后添加构建过程, 复制以下代码:
# This is a basic workflow to help you get started with Actions
name: sync code to gitee
# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the master branch
# on:
# push:
# branches: [ master ]
# pull_request:
# branches: [ master ]
on: [push, pull_request]
# 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"
sync_gitee:
name: sync repo to gitee
# 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
- name: checkout code from github
uses: actions/checkout@v2
# Runs a set of commands using the runners shell
- name: sync shell cmd
run: |
GITEE_GIT_ADDR="git@gitee.com:Sipeed/maixpy_scripts.git"
git fetch --unshallow
SSHPATH="$HOME/.ssh"
rm -rf "$SSHPATH"
mkdir -p "$SSHPATH"
echo "${{ secrets.GITEE_SYNC_ACCESSS_KEY }}" > "$SSHPATH/id_rsa"
chmod 600 "$SSHPATH/id_rsa"
sudo sh -c "echo StrictHostKeyChecking no >>/etc/ssh/ssh_config"
git remote add upstream $GITEE_GIT_ADDR
git push upstream --all --force --tags
这里注意,有几个地方需要简单修改一下:
GITEE_GIT_ADDR这个变量是 gitee 仓库的地址, 注意是 git地址而不是https地址。
还有GITEE_SYNC_ACCESSS_KEY这个变量就是前面我们在 github仓库设置的变量, 之前名字如果不是这个,也需要修改成一样的。
创建后,右上角点击提交即可,代码更新后会自动触发构建, 可以到Action里面看进度和结果,有什么错误修改一下就好了。
其它
这里手动建立仓库, 也有其他人做了 action 里面自动建立仓库的, 但是需要在gitee再生成一个key,所以少了一步创建仓库,多了一部生成 key, 并没有将过程变得更加简单,可能对于有多个仓库有一定的作用, 但是我希望代码越少越好,越简洁越健壮越好维护,就这样使用吧,哈哈哈哈。
另外也没有打包成 action market 可以使用的公用包, 因为功能就这么简单,复制粘贴的事情何必做那么复杂, 而且方便根据自己的情况直接修改.
from http://web.archive.org/web/20210806032330/https://neucrack.com/p/331
------------------------------------
通过GitHub Action将博客网站等静态文件同步到云服务器
借助Github action(使用easingthemes/ssh-deploy)将hexo静态博客同步到云服务器,实现自动化部署。
最近在折腾mkdocs,再次使用到通过Github Action将自动生成的静态文件部署到云服务器功能。这里做些详细总结,笔记。
将文件同步到远端服务器,可以使用ftp,sftp,ssh等协议。对于云服务器,通过ssh协议同步文件是很好的选择。这里我介绍的easingthemes/ssh-deploy即是利用Liunx/Unix下的rsync(remote synchronize)工具,借助ssh协议,实现本地端(Github)与云服务器端的文件同步。
在Github marketplace商店里能搜索到很多与easingthemes/ssh-deploy类似的同步工具,原理及使用大同小异。
ssh-deploy代码示例
采用ssh-deploy同步文件的代码示例:(可任意命名为.github/workflow/ci.yml)
1 | ## 部署到服务器 |
以上,Github action与远程VPS连接,采用ssh方式登录(通过私钥),rsync同步文件。
为安全,将私钥托管到Github,然后采用变量表达(比如secrets.SSH_PRIVATE_KEY_BJ_IPC )。如此,VPS的IP地址,用户名,同步的目录等参数均可托管到Github,然后采用此种变量表达,以避免明文暴露。
托管VPS的私钥
生成公私钥
登录vps,键入以下命令,生成公私钥。在.ssh目录下,会生成两个文件,id_rsa 为私钥,id_rsa.pub 为公钥。
1 | ssh-keygen -m PEM -t rsa -b 4096 |
键入以下命令,将公钥导入authorized_keys文件
1 | [root@host ~]$ cd .ssh |
如此便完成了公钥的安装。为了保证连接成功,确保以下文件权限正确:
1 | [root@host .ssh]$ chmod 600 authorized_keys |
配置ssh,打开密钥登录功能。
编辑 /etc/ssh/sshd_config 文件,进行如下设置:
1 | RSAAuthentication yes |
重启 SSH 服务:
1 | sshd restart |
到这里还有一个很重要的步骤:需要将私钥转换成pem格式:
1 | ssh-keygen -p -f ~/.ssh/id_rsa -m pem |
打开id_rsa,看看开头是不是—–BEGIN RSA PRIVATE KEY—–
托管私钥
Github里配置私钥。对应的项目仓库,Settings-> Security-> Secrets and variables-> Action-> Secrets将私钥托管在此处。
选择New repository secret。
Name,自己命名,比如上述代码里命名为 SSH_PRIVATE_KEY_BJ_IPC,秘钥变量即为secrets.SSH_PRIVATE_KEY
1 | SSH_PRIVATE_KEY: ${{ SSH_PRIVATE_KEY_BJ_IPC }} |
Secret,将上述id_rsa文件(—-BEGIN RSA PRIVATE KEY—–开头的),全部复制粘贴。即完成了私钥托管。
rsync参数
easingthemes/ssh-deploy使用Linux rsync工具来同步文件。在rsync主页对其使用,常见参数有详细介绍,这里选择重要的命令参数总结在下面:
Short | Long | Description |
---|---|---|
-a | –archive | 归档模式,表示以递归方式传输文件,并保持所有属性,它等同于-r、-l、-p、-t、-g、-o、-D 选项。-a 选项后面可以跟一个 –no-(OPTION),表示关闭 -r、-l、-p、-t、-g、-o、-D 中的某一个,比如-a –no-l 等同于 -r、-p、-t、-g、-o、-D 选项。 |
-v | –verbose | 表示打印一些信息,比如文件列表、文件数量等。 |
-z | –compress | 传输过程中进行压缩。 |
-r | –recursive | 表示以递归模式处理子目录。如果单独传一个文件不需要加 -r 选项,但是传输目录时必须加。 |
-l | –links | 表示保留软连接。 |
-L | –copy-links | 表示像对待常规文件一样处理软连接。如果是 SRC 中有软连接文件,则加上该选项后,将会把软连接指向的目标文件复制到 DEST。 |
-p | –perms | 保持文件权限。 |
-t | –times | 保持文件时间信息。 |
-g | –group | 保持文件属组信息。 |
-o | –owner | 保持文件属主信息 |
-D | –devices –specials | 保持设备文件信息。 |
-u | –update | 把 DEST 中比 SRC 还新的文件排除掉,不会覆盖。 |
–delete | 删除 DEST 中 SRC 没有的文件。 | |
–exclude= | 排除不需要传输的文件,等号后面跟文件名,可以是通配符模式(如 *.txt)。 | |
–progress | 显示同步的过程状态,比如同步的文件数量、 同步的文件传输速度等。 | |
rsync是增量备份同步,速度和可靠性都很好。
值得一提的是使用–delete这一选项,SRC中的文件及文件夹的任何改变都会同步到DEST,同时DEST中的如果有新增文件,使用–delete同步,DEST新增的这些文件会被删除。
Cache
在使用Github action生成mkdocs站点,然后托管到VPS过程中,发现每次mkdocs的deploy的时间都很久,看日志,大部分时间都花在了安装mkdocs的依赖库及环境上,而这些明显是可以缓存的。搜索了下,果然Github有cache action可以实现对环境及依赖库文件的缓存。Github cache action有中文的说明文档,但对如我一样的new hand,使用配置太过复杂,看了文档也不知道怎么用。一时陷入僵局。想到自己在同样通过Github action部署hexo时,deploy速度明显比mkdocs要快(Github action的workflows借鉴自网络,当时没深究),起初以为是hexo部署本身就要比mkdocs快。看了下对应的Github action的workflows文件,发现有个名为c-hive/gha-yarn-cache的Github action,恰恰就是用来缓存依赖库及环境文件的(最初我以为是来缓存生成的hexo静态文件的)。
看看gha-yarn-cache给自己的介绍:
1-liner yarn install cache for GitHub Actions.
GitHub Action caches improve build times and reduce network dependencies. However, writing the correct cache logic is tricky. You need to understand how the cache action (keys and restore keys) work. Did you know you’re not supposed to cache thenode_modules
folder? The setup is different per OS and takes a lot of space in your workflows. Not anymore!
哈哈,恰恰是对于像我这样不知道如何使用配置 Github cache action的new hand的。马上使用之。
-------------------------------------------------------------------
Github action
hexo博客的部署方式千千万,借助Github action可能算非常优雅的一种。hexo代码托管在Github,Obsidian拟写新博文后,自动发布到Github,触发Github action,完成构建hexo,生成静态文件,同步到对应的目标。这对应的目标可以是S3对象云存储(比如腾讯云COS,阿里云OSS等),也可以是云服务器,FTP空间,甚或serveless服务等等。
目前我用到的Github action命令和步骤有:
- actions/checkout@v2(检出代码);
- actions/setup-node@master(安装node.js);
- c-hive/gha-yarn-cache@v1(缓存生成的hexo静态文件);
- easingthemes/ssh-deploy@main(通过ssh将静态文件发布到到服务器)。
第4步,除了通过SSH发布到服务器,还可以发布到对象云存储(deploy to COS),FTP空间等,对应的Github action命令可以自行搜索。
另外借助Github action,网站还能同时托管于netlify,vercel这样的serveless平台。利用dnspod分区解析功能,使国内用户访问位于国内服务器的网站,国外用户访问托管于serveless平台的网站。网站数据完全一致。
--------------------------------
deploy to COS
这个hexo博客代码托管在Github,Netlify构建静态文件,然后套上国内的cdn。唯一的问题是无论是直接用Netlify自带的cdn,还是套国内的cdn,总感觉不够丝滑。问题出在哪儿是显而易见的。
某天突然顿悟,为什么执迷于一定要部署到Netlify?hexo这样静态博客的优点不正是部署方式的多样性吗!除了类似Netlify这样的serverless平台,对象云存储,FTP,linux主机(通过Rsync部署),git仓库,ipfs等等都可以部署hexo。(参见hexo部署)
因为经常用,决定把这个hexo博客迁移到腾讯COS。
源自WordPress时代保持下来的好习惯,博客站点动静态资源分离,图片,JS等静态资源都托管于第三方的存储,因而剩下的工作会很简单,可以使用诸如hexo-deployer-cos这样的插件。但是我这个博客目前只能运行于nodejs 14.x(博客主题老旧原因),就不使用插件方式,不动博客代码本身了。适合用Github action自动构建hexo,然后推送到cos。
方法很简单,在Github action新建一个自动化任务 .github/workflows/cos-deploy.yml,代码如下:
1 | # workflow |
在Github设置里新建4个密码变量,分别是secrets.TENCENT_CLOUD_SECRET_ID,secrets.TENCENT_CLOUD_SECRET_KEY,secrets.COS_BUCKET,secrets.COS_REGION。对应的值(id,key,cos桶名称,地域)可以在腾讯COS里设置查询。
以上代码可以根据自己的需要修改,比如Github仓库的分支(main),node版本等。上述自动化的流程是,先从 Github仓库中检出代码,然后在action里缓存,接着构建hexo的静态文件,然后通过腾讯云的coscmd工具上传到相应的cos桶里。
最后一行命令 coscmd upload -rs –delete ./public/ / -f 目的是比较cos存储桶内的文件,如果有变更则更新,如果cos中存在但hexo的public目录中不存在,则删除对应的文件。腾讯云的coscmd工具的使用可以参见官方文档。
hexo的public目录上传到cos以后,绑定域名,就可以访问了。COS提供了自定义源站域名,cdn加速域名,全球加速域名三种选择。因为我站点的静态资源已经cdn了,此处完全没必要再次cdn加速,因此我使用了自定义源站域名。而全球加速只适用于有在多个不同地区上传文件到cos的需求。
通过测试,发现即使使用的是自定义的域名,ping出来仍然有多个ip,网站访问速度比netlify+国内cdn好很多,个人体验也更丝滑。(心理作用?)
---------------------------------
利用 Github Actions Caches 来缩短打包时间
在 Astro 的官方文档上看到 Astro 有配置参考中提到的 cacheDir1,立马想到可以利用这项配置来缩短在 Github Actions 上打包的时间。
因为之前有配置过 Github Actions Caches 的经验,因此稍微修改一下触发 Github Actions 的 yml 配置文件就线上测试了。
线上测试结果满足了自己的需求,参照对比如下:
配置成功后可在 Actions -> Caches 中找到缓存列表
没有缓存时
开启缓存后
以下为个人 Github Actions 配置,供参考。
name: Deploy Astro site to Pages
on:
# Runs on pushes targeting the default branch
push:
branches: ['astro']
# Allows you to run this workflow manually from the Actions tab
workflow_dispatch:
# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
permissions:
contents: read
pages: write
id-token: write
concurrency:
group: 'pages'
cancel-in-progress: false
jobs:
build:
name: Build Astro Blog
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Setup Node
uses: actions/setup-node@v4
with:
node-version: '20'
- uses: pnpm/action-setup@v3
name: Install pnpm
with:
version: 8
run_install: false
- name: Get pnpm store directory
shell: bash
run: |
echo "STORE_PATH=$(pnpm store path --silent)" >> $GITHUB_ENV
- uses: actions/cache@v4
name: Setup pnpm cache
with:
path: ${{ env.STORE_PATH }}
key: ${{ runner.os }}-pnpm-store-${{ hashFiles('**/pnpm-lock.yaml') }}
restore-keys: |
${{ runner.os }}-pnpm-store-
- name: Cache Astro build artifacts
uses: actions/cache@v4
with:
# Astro cacheDir Path
path: ./node_modules/.astro
# Detects whether the image in this path has changed
key: ${{ runner.os }}-astro-cache-${{ hashFiles('src/assets/images/**') }}
restore-keys: |
${{ runner.os }}-astro-cache-
- name: Install dependencies
run: pnpm install
- name: Build
run: pnpm build
- uses: webfactory/ssh-agent@v0.9.0
with:
ssh-private-key: ${{ secrets.AL_DEPLOY_KEY }}
log-public-key: false
- name: Scan public keys
run: |
ssh-keyscan ${{ secrets.AL_DEPLOY_HOST }} >> ~/.ssh/known_hosts
- name: Copy
run: |
rsync -av dist/ laomaiorg@${{ secrets.AL_DEPLOY_HOST }}:/laomaiorg/project/blog/html
- name: Deploy
uses: peaceiris/actions-gh-pages@v4
with:
deploy_key: ${{ secrets.ACTIONS_DEPLOY_KEY }}
external_repository: laomaiorg/laomaiorg.github.io
publish_branch: main
publish_dir: ./dist
我博客上的图片只有 295 张,在 Github Actions 上总耗时能缩短 1 分钟。虽说,或者,看起来作用不大,但是既然可以如此操作,为什么不利用起来呢?毕竟 Github Actions 也是计算使用时长的,每月 2000分钟。当然,这额度对于普通的个人使用的话是足够了的。
No comments:
Post a Comment