背景

最近业务上有一个需求，要支持把 xmind 文件转换成 pdf。找了一圈没找到命令行工具，所以打算搞个虚拟机，然后自动化控制 xmind 客户端导出。

然后就到控制的环节了，这边还要支持定时任务，所以抽象一下，需求如下：

执行任务（只能 windows）
定时添加任务
获取输出的文件

接下来就是选型了

自研调度平台

这个其实很早就有想法了。

1
2
3
4
5
6
7
8
9


sequenceDiagram
	participant A as client
	participant B as manager
	participant C as runner
	A ->> B:提交任务
	B ->> C:发布命令
	C ->> B:返回结果
	A ->> B:查询结果
	B ->> A:返回结果

其实不难，manager 起一个 http server，runner 轮序，全异步。文件存储在 manager，客户端请求的时候返回。

但是仔细想一想，这个好像，，，和 github action 有点像？

Github Action

老朋友了。

runner 管理和文件存储（packages）都有了，client 方面，查了一下，支持 webhook 调用。

但是网络问题难搞，总不能把业务的稳定性寄托于网络稳定性吧。

Gitlab Ci

和上面差不多，但国内网络好很多。

Gitea Action

网络还行，但是官方 SasS 的版本好像不支持 packages，必须要自建。

Update

好像踩坑了。。。

因为我输入是文件，输出也是文件。

输出简单，上传到 artifact 里面，或者直接进 s3 到生产上了。

输入的话，人家设定的应用场景就是对仓库内的代码进行检查和部署，输入都在代码里面，外界传入的最多就是些环境参数。而我这，，，把这玩意当成任务调度系统了。。。

不好搞。。。

效果

工作流

最后用 Github Action 做出来了。

整体是这样一个流程，最前面使用发送 post 请求的方式触发，同时传递业务的参数。每个 step 只做一件事情，step 之间使用 artifact 中转产物，最后再把产物上传到阿里云，就完成了整一个生成的流程。

定时触发

按照业务需求，还需实现定制执行功能。具体是分别每天，每月，每季度都要执行一次。

遵照开闭原则，我又引入了三条 workflow，专门用来触发上面的构建 workflow。

但是这里又遇到了点问题，因为定时执行是由 Github 的服务器触发的，采用的是 UTC 时间，比本地时间慢八个小时，这是不可以接受的。经过一番搜寻，找到了这个仓库和这个网站，可以把本地 cron 转成 UTC 的 cron，非常棒。

算是完美完成了任务吧。

Github Action 完成度太高了，可以使用自托管 runner 运行，支持在容器里面运行，云端还看的到所有命令的输出，几乎无限制的 artifact 存储，除了在本地运行有点麻烦之外，简直是完美。🥰🥰