起因#

如同des所说，我们做过网站的都知道，如果你利用Pr来处理友链，特别是没有自动化的那种，那大概率你会得到

多？数量并不是问题，问题在于

和一位？

是的，我都没有自创格式了，很多人提个友链连JSON都写不明白，上图是忘引号的，下图还有个忘后缀的（我的宝贝你 .json 呢）

老早之前至今刚刚，我都是帮他们改的，毕竟感觉这都是小问题

但是，当你在打游戏的时候突然弹一个友链Pr，又或者在干正事的时候弹出来，你要处理它吗？又或者等着一起处理？无非是现在立即赤石和以后慢慢吃依托史的区别

那么有没有办法把这坨史转嫁一下呢？

正式开始#

我们是否可以通过Github Action来自动化这件事？

让用户提交友链的时候再添加一个回链字段，然后让Github Action实际测试是否有回链，这不仅能确保对面添加了你的友链，也能顺便做好所有权验证

正式开始（旧的）#

我们可以通过我们超高校级的大脑思考一下

Github Action是做什么的？这不刚好符合我们想要做的事情吗？甚至还可以做一些高级的东西（比如所有权验证） 神似必应谷歌网站管理员添加域名

那么我们灵机一动，这坨大纲就出来了

接下来交给AI，让他写

最终你就得到了

没事，乱只是暂时的，谁让Github Action只能在生产环境测试呢（笑）

最终我们就会得到…

哈哈，是不是非常的简单？No！看着逻辑清晰实则这个逻辑清晰是理了半小时然后又改改修修半小时做出来的基本能用的

那么下面就写一些很容易踩坑的东西

踩坑#

首先就是这一整个架构虽然逻辑清晰，但是逻辑十分复杂，如果说一次就能跑通那就谢天谢地，如果一次不行你连Debug都不知道怎么D

所以在我的超级大脑深度思考40s迭代了3次架构图后，我毅然决然选择了适用Github的标签来跟踪进度和锚定规则

每一步都明确给Pr打上特定的标签，就像…这样！

这不仅使每一个Pr在外面看就知道是哪出了问题，也能让你在不写log的情况下大致知道问题出在哪

接下来就是我们做所有权验证，这个东西其实是需要做错误处理的，它往往并不能一次性跑到底，得益于Github标签，我们可以通过打特定标签来跳过/不跳过某些步骤，避免验证文件被重复要求或者每次都会随机一个新的出来

只要添加了 所有权验证进行中 Action就会找之前创建的要求验证的文件，而不是再生成一个新的

好吧这看来只是基本功，但是接下来不一样！

我发现只要是外部仓库拉进来的Pr，Action是没法通过 GITHUB_TOKEN 来合并Pr的，到也不麻烦，你创建一个自己的个人访问令牌（PAT），再绑定到Action就是

至此，睡觉！