why
为什么要做、背景
最近给umi写一个机器人,用于邀请新人进 umi contributor 群,希望有更多人来参加建设。umi是个react开箱即用的开源处理计划,概况能够看官网。
PR概况看:ci: PullRequest Checker by txp1035 Pull Request #10319 umijs/umi GitHub
what
处理计划是什么样子,做好后达成什么效果
- 非 doc pr 被合并时,发个音讯
感谢 PR。假如有兴趣一同参加维护 Umi,可先用钉钉扫下方二维码(注明 github id)加我钉钉,然后我会拉到群里。+图片
- 假如已经在群里或许有库房write权限的同学就不发送音讯了
how
怎样完结的
首要是经过gitHub action来完结的。 不了解gitHub action的朋友能够看GitHub Actions 入门教程 – 阮一峰的网络日志
文件放在项目里的.github/workflows
剖析条件
非 doc pr 被合并时
这儿拆分成两个条件来处理
- 非 doc 提交。在umi中,文档的改变都是在
docs/**
里的,所以用户只改动这个文件夹里的文件忽略履行action就行了。当然也能够去判别pr的标题是不是doc:
来过滤。假如你知道欢迎评论~ - 被合并的时分。就是在pr封闭时,判别这个pr是不是被合并的状态。前者在on做判别,后者在jobs做判别。
发个音讯 `感谢 PR
这儿用到了一个第三方action,actions-cool/maintain-one-comment@v3。就用用来发送音讯的,装备这个需求打开设置,给机器人权限,不然会报错。
判别条件不发送音讯
不发送音讯有两个状况:
- 在钉钉群里的同学不发送音讯
- 有库房write权限的同学不发送音讯
先解第一个问题,计划是维护一个数组json文件,文件里维护群里同学的github id。然后判别提交者是否在这个数组里边,在就不发送音讯。这儿经过juliangruber/read-file-action@v1读取文件、contains方法来判别提交者(github.actor)是否在这个数组(fromJSON(needs.read-file.outputs.require-result))里边。
再解第二个问题,这儿直接经过actions-cool/check-user-permission@v2库就能知道用户是不是有权限。
详细源码如下:
name: PullRequest Checker # 姓名,随意取,契合你自动化的主题就行
on: # 满意什么条件触发
pull_request_target: # pr封闭的时分
types: # pr封闭的时分
- closed # pr封闭的时分
paths-ignore: # docs下目录内容改变忽略
- 'docs/**' # docs下目录内容改变忽略
jobs:
read-file: # 姓名,随意取,契合你自动化的主题就行
runs-on: ubuntu-latest # 在什么渠道运转
outputs: # 选项
require-result: ${{ steps.contributors.outputs.content}} # 导出参数
steps: # 履行什么事情
- name: Checkout # 姓名,随意取,契合你自动化的主题就行
uses: actions/checkout@v1 # 检查库,不然读取不到文件
- name: Read contributors.json # 姓名,随意取,契合你自动化的主题就行
id: contributors # 文件导出的字符串存储的变量
uses: juliangruber/read-file-action@v1 # 读取文件插件
with:
path: ./contributors.json # 途径参数
check-permission: # 姓名,随意取,契合你自动化的主题就行
runs-on: ubuntu-latest # 在什么渠道运转
outputs: # 选项
require-result: ${{ steps.checkUser.outputs.require-result }} # 导出参数
steps: # 履行什么事情
- uses: actions-cool/check-user-permission@v2 # 权限插件获取用户插件
id: checkUser
with:
require: 'write'
check_merged: # 姓名,随意取,契合你自动化的主题就行
runs-on: ubuntu-latest # 在什么渠道运转
needs: [read-file, check-permission] # 导入参数
if: needs.check-permission.outputs.require-result == 'false' && contains(fromJSON(needs.read-file.outputs.require-result), github.actor) == false && github.event.pull_request.merged == true # 发送音讯需求满意的条件
steps: # 履行什么事情
- uses: actions-cool/maintain-one-comment@v3 # 发评论插件
with:
body: 感谢 PR。假如有兴趣一同参加维护 Umi,可先用钉钉扫下方二维码(注明 github id)加我钉钉,然后我会拉到群里。<img src="https://www.6hu.cc/wp-content/uploads/2023/02/1676451309-42c861c9c327cfc.png" width="20%"/>
后记
github action我也不常用,所以记载一下踩坑和处理方法。
踩坑
- 他人action写readme的不一定合适新手, 假如依照action的README文档运用履行失利能够到库房里找找比方,或许它还依靠其他的action。并且直接看库房比方也更直观,比方在
.github
文件夹下面。 - 调试:由于我这个需求是做pr封闭来的,我自建了个库房一向经过建立pr的方法进行调试,快完结的时分反应过来了,经过push触发action更快~I’m so stupid.
处理方法和技巧
- 推荐在官方文档查api,输入对应关键词。
- 假如api都懒到不想看,能够试试谷歌。首要原因是文档不能针对action进行查询有点不友好。
- 假如功能杂乱能够先试试看action社区里查找下。
- . 由于action日志输出对象是个object,所以想知道里边是什么能够经过toJSON这个方法来转成字符串,不过这个方法也或许失灵,比方打印gihub这个上下文,详细原因还没有查,我猜里边有无法序列化的东西。我想到的只能是看api,有知道怎样能打印出来的的大佬能够告诉我~thanks
闪念
经常做需求就会给自己挖坑,脑子会蹦出一些好玩的想法。比方做这个机器人,我就想可不能够守时基于钉钉群人员姓名自动更新github共建者列表,或许经过能够@机器人添加。这个单纯是好玩的想法ROI有点低哈哈。
最终
祝我们元宵节高兴。欢迎运用umi,假如你运用过程中遇到问题能够提issue,也欢迎提pr处理。
参考
表达式 – GitHub Docs
docs.github.com/en/actions/…