摘要:本文记录在配置使用 CircleCI 来自动化部署 Latex 时遇到的问题,希望通过该文,能够避免犯同样的错误,同时也可以快速搭建 CircleCI 的配置部署 。
目标
在使用 Latex 撰写文章的时候,有时候需要将编译好的 PDF 发布到线上,如果需要不断更新文章的版本,就需要手动生成 PDF,然后更新线上 PDF 的版本,这个过程步骤虽然不多,但是十分繁琐,再加上如果有其他的更新操作,就会在发布新版本的时候越来越复杂。那么有什么办法可以自动化完成这个更新部署呢?
那就是持续集成 (CI),如今的持续集成绝对不仅仅是代码的持续集成,任何能使用命令自动化完成的东西都可以考虑用自动化持续集成,这将会极大程度的降低重复劳动。
虽然研究持续集成脚本的编写十分费时,有时候如果不熟悉构建的环境还需要不断的尝试才能最终达到希望的效果。但是这绝对是一劳永逸的工作。
下面本文将会使用 CircleCI 来完成这个持续集成部署的过程,同时也穿插一些 CircleCI 使用中的注意点。
CircleCI 配置基础
首先我们先熟悉一下 CircleCI 的配置方法,之前介绍过使用 Travis-CI 来部署 Hexo 博客。Travis-CI 免费版只能支持 Public 的 Repository,而 CircleCI 是针对构建资源进行限制,所以这一点上 CircleCI 更适用于个人使用。
配置文件
不同于 Travis-CI (在根目录创建配置文件.travis.yml), CircleCI 是需要创建一个 .circleci 的文件夹,然后将 config.yml 文件放入该文件夹中来执行持续集成的。原理大同小异,通过定义 YAML 的语法来执行命令。
基础配置
首先我们可以先纵览一下整个配置文件,简单了了解下配置文件的结构,下面有详细的注释说明配置文件项目的用途。
1 | # 版本号,这里推荐使用版本2,版本1近期可能会退役 |

Workflow 与 Context
CircleCI 有一个 Workflows 的概念,具体可以参考官方文档,我们这里使用 Workflows 并没有使用太多高级功能,只是用到了一个 Context 概念,个人觉得这个 Context 的理念十分方便,之前在 Travis-CI 中每个项目都要定义若干环境变量 (安全目的,尤其是一些Token),但是 CircleCI 可以在个人配置中配置一个 Context 也就是一组变量,然后这个 Context 可以在多个项目中共享。比如个人 GitHub 的用户名和邮箱这种变量就可以放到这个 Context 里面。具体配置方法如下:
1 | workflows: |
这里需要注意 Context 放置的位置,根据官方文档和自己的实践发现,这个 Context 好像只能放在 Workflow 中的 Job, 不能直接放在 Job 的定义中。
注意点
- 执行 shell 脚本之前可能需要为其加入执行权限
chmod -x xxx.sh。 - 有些指令,比如安装指令
apt-get都只能在run中执行,不能在脚本中执行。
部署配置
整体思路
参考该网站的开源程序的配置,它的目标和本问题有些相似。
这里主要有两个 Repository,一个是私有,保存了 Latex 的源文件,另一个是公有,作为PDF外链存储仓库。假设分别 source 和 publish。
我们的自动化部署总的来说就是:使用 source 构建 PDF 文件,然后再用一种机制更新到 publish 仓库中。
Latex 编辑
现在云端应用越来越强大,基本能像都的服务都能在云上找到相应的产品。同样 Latex 的编辑器也用,之前有两个比较不错的 ShareLatex 和 Overleaf,现在 Overleaf 收购了 ShareLatex,目前 Overleaf V2 功能十分强大。而且它支持 GitHub 同步,这样 Overleaf 无缝融合到本自动化部署的内容更新端。
版本 Release 控制
一般情况下,我们会使用 Git 来通过 Tag 来管理发布版本,但是 Overleaf 还不支持 Tag 的同步操作,所以我想了一个方案,在 CircleCI 的配置文件夹中加入一个版本的文件 latest-version.txt,同时在发布的仓库中加入一个版本文件 version.txt。这样每次希望发布新版本的 PDF,只需要更新这个 latest-version,这个版本会大于 version,只要 latest-version 大于 version 那就发布新版本,并修改 version 为最新,等待下一次更新 latest-version。
流程
- 使用
Overleaf编辑Latex,同步到GitHubMaster分支 - CircleCI 触发执行
- 下载源码,使用 xelatex 编译,这里需要和
Overleaf的配置一致。生成了PDF文件。 - Git 检出 public 仓库,
latest-version大于version,那么开始更新,首先将当前最新的PDF替换为新版本,同时将最新的PDF另存为对应的版本名称,用于归档。 - 将 public 仓库的更新提交并推送到GitHub中。
- 发布的网页比如
PDF viewer,使用最新版本链接,这样不用更改网站配置,就可以同步显示最新的PDF了。
Bash 脚本遇到的问题
- 需要理清楚路径
- 在执行脚本的时候,可以指定参数,并且在脚本中可以获取该参数
- 有些命令可能需要依赖安装包,这个需要检查,否则会出错。比如一个比较版本的函数就依赖
test,sort等,所以无法执行,这里只检测了版本号是不是一样。 - if 语句的写法一定要注意,加空格,加中括号
- 多定义变量
下面附上脚本源码
1 |
|