GitHub Action 开发杂谈

浅蓝喜灰

居然更新了

眨眼间就到2025年了,距离上一次更新已经过去了近两年(准确说只有一年多一个季度不到),是时候重新拾起这篇博客。往常我喜欢在博客里面写一些自己的开发参考,例如先前我写过的Hexo博客部署教程,我几乎每次更新Hexo、重新构建的时候都会把那篇博客重新翻看一次;再比如关于Git for Windows安装和使用的篇章,有段时间忙于复习,等到考完时再上手Git,也会重新翻看一遍那些文章。这些文章(我自认为)写得还行,尽管它可能没有那么全面,也不一定完全正确,但至少帮到了我(希望也能帮到其他人)。

不过,话又说回来,每写一篇那样的文章都费时费力,我至少要花两到三天,每天一有空就得开始写这些文章,反复琢磨其中介绍内容的正确性,即便如此也不能保证每一篇都尽善尽美,这样的流程让我对写博客这件事逐渐丧失兴趣,因此停更了很长一段时间。

在最近几个月,我参与到LearnOpenGL的中文本地化工作时,因为等翻译PR合并的过程太无聊,于是便四处翻看,偶然翻进其中某位大佬的博客,里面有不少杂谈文章,越看越上头,再加上前阵子有个面试官问我为啥博客很久不更新(我前面的面试都没有任何一个面试官看过我的博客——至少他们从没提问过这方面的东西,但这次面试的面试官看了并且有提问,真是令我印象深刻),于是便萌生了转方向写杂谈的想法。

背景故事

闲扯蛮多了,来聊聊GitHub Action吧。

在开发GitHub Action的时候,我突然想起来,疫情期间学校要求填报各种健康状况汇报表,我用Python做了一个自动填报的小程序,挂载在当时还有免费额度的华为云的云函数上,我的程序每天都会定时运行,并在发生错误的时候发送邮件到我的邮箱。

GitHub Action虽然也可以实现类似的功能,不过两者的侧重点显然是有所不同的,因为我本人没有深入用过云函数,所以我就不细究它们之间的区别。

大概是在掉粉追踪这个仓库开发完成的前几天,我看了码农高天的视频,于是有了开发一个小项目的想法,这个小项目不能太难,最好还得是能为我所用,比如说要我重做一遍危险驾驶行为检测系统,它既不能指导我怎么开车,难度也不低,那我肯定是不会乐意做下去的。恰好我想到许久以前,有人反复关注我的GitHub又取关,连带某个仓库也是反复Star和取消Star,每次看到他重新关注和Star的时候我都会在想,这家伙前几天不是才关注过我吗?怎么又关注上了,还是给我整上达利园效应曼德拉效应了?于是我便有了个想法,既然GitHub在用户取关时不会通知,那我何不做一个小程序,记录取关的用户?非常有趣的想法,于是我就开始思考这个项目的可行性。

预估开发难度与可行性

既然是要记录取关的用户,那么首先肯定要先知道自己的关注者。按理来说,GitHub有API去做这些事情,但考虑到我只需要读取到一个用户的关注者列表,无需做出写入操作,所以大可以直接请求GitHub的网页,然后按照特定逻辑(一般会用正则表达式)提取用户名字、用户名之类的信息,提取出来后与本地存储的信息进行一个比对,记录减少的用户即可。

简单看了一眼GitHub关注者网页的源代码,是比较规律的,所以提取和比对的操作应该非常简单;请求网站的源代码可能会涉及些许速率控制,不过本项目预计的请求频率是一天一次到三次这样,平均下来最频繁不过八小时一次,唯一麻烦的是,由于DNS污染以及SNI阻断之类的存在,让本地对GitHub发起的请求有一定概率失败。尽管用TUN模式可以搞定这个问题,但我没钱搞一个自己的海外IP,只能使用那些其他人也在用的IP,如果其他人干了什么坏事,IP被拉黑了,那我的这个请求也别想发出去。

虽说困难总比办法多,但这一次我们还是有办法搞定的。GitHub提供了一个名为Action的工具,我们可以用它来执行一些操作,不需要在自己的电脑或者是物理服务器上。

话是这么说了,实际上怎么写呢?恰好我许久之前,在哔哩哔哩上看到了一个GitHub仓库,它可以定期爬取指定Steam用户的好友列表,用的就是GitHub Action,其工作流程和我的需求基本一致:定期执行某一个仓库里面的脚本,将执行结果重新推送回仓库。有了参考,那么陌生的GitHub Action自然也可以快速熟悉起来了。

实际上手

关于写增删改查什么的就不多讨论了,它既没有什么技术难点,也不是本篇的讨论中心。本节想聊聊的是GitHub Action这个功能。

最开始我是看的GitHub官方文档,里面逐一介绍了一个Workflow的配置文件是如何写的,各个元素的用处,非常详细。不过它给的示例都不太能符合我的想法,要能完全理解并且能够自己写出来,那要花不少时间,所以为了节约时间,我直接打开了先前那个爬取Steam好友列表的仓库,找到了它的Workflow,原封不动复制过来。不过呢,直接复制过来也不可能工作得起来,所以我还是打开了GitHub Action的文档,比对着修改。

整个的编写流程其实不长,yaml的格式也是接触不少了,很快就能理解清楚,主要还是其中的一些疑似是Action的语法相对不好理解,不过没关系,GitHub Action文档里面也已经写有一些参考了,只需比对一下文档给的写法和范例里面的写法,便能很快地理解清楚。这比单纯地看文档然后自己写要快得多,毕竟已经有一个现成的参考,当然也比照着参考然后自己上网搜快得多,因为网上的介绍往往较为浅显,稍微涉及一些深入的语法往往就要花费大量时间搜索。

经过一个下午的battle,总算是把Workflow给写出来了。找了几个朋友实验,只排查出了一些排版问题,至于Workflow的配置,没有出什么大问题。总的来说还是比较满意的。

杂谈

话说到查资料这部分,我发现国内充斥大量AI洗稿文章,同样的内容,能给许多人发布成几十篇不同的文章,要不就是把一些国外网站内容例如Stack Overflow给机翻然后搬回来,更神奇的是他们居然还能用好几个机器人账户自问自答,搞得跟真的一样,试想一下,谁会用机翻中文提问和作答?外国人不是应该直接用母语或者英语吗?此外也有的是直接把国外那种终极灌水文搬回来,品完国内的小编体,又接着品翻译回来的国外小编体,真是无穷无尽。

要说的话,我们确实可以用英文+谷歌搜索+关键词排除来降低看到垃圾文章的频率,但直接屏蔽掉国内用户的内容,又使我错过了太多有用的信息,也给我造成了不便,毕竟不是在英语环境下写的代码,有些专有表达不一定知道,这就会进一步降低了搜索信息的效率,例如要搜段间距设置,我在不知道的情况下,会错误认为是gap between paragraph,而实际上,更合适的表达应当是spacing between paragraph或者类似的组合,当然了我这里只是举个例子,实际上搜索引擎会对这个例子进行一些优化,当你搜gap between paragraph时,搜索引擎会为你呈现spacing between paragraph的结果,但若换到其他冷门一点的概念,搜索引擎就未必能做出如此优化,所以使用纯英文检索,完全排除中文信息,不仅少了不少潜在的优质内容,也造成了许多不便,乃至有可能因为用语习惯导致错失了更多的信息。最后我们还得是继续用回中文检索,尝试在被AI污染的结果中,找出不那么糟糕的那个。