v3.25.0:自动化场景打通GitHub/GitLab

主要更新内容:

  1. 新增GitHub连接器(4个触发器、1个动作和2个属性条件)
  2. 新增6个PingCode与GitHub的自动化场景模板
  3. 新增GitLab连接器(4个触发器、1个动作和2个属性条件)
  4. 新增6个PingCode与GitLab的自动化场景模板
  5. 新增3个重要动作

在v3.25.0版本中,PingCode打通了GitHub和GitLab,因为它们的场景较为相似,因此放在一起进行说明:

场景1:在PingCode Agile中创建“任务”时,自动在GitHub/GitLab中创建分支。这个自动化模板适用于使用git-flow的开发团队,它会定义一种标准,那就是:首先通过PingCode Agile创建研发任务,然后开发人员基于这个任务对应的分支进行开发。

场景2:在GitHub中创建PR(在GitLab中创建MR)时,自动将对应的“任务”设置为“Code Review”状态。这是场景1的延续场景,当开发人员完成开发,向主分支提交PR/MR时,这个源分支对应的“任务”(当然也可以是PR/MR标题中包含的相关“任务”)的状态会自动变更为“Code Review”,同时系统会向“任务”中增加一条评论,告知PR/MR的主要信息,甚至可以@相关的开发人员来进行Code Review。

这个自动化的规则是这样的:

场景3:当GitHub的PR Review状态发生变化(在GitLab中创建MR Comment)时,自动提示对应的任务负责人。这是场景1和场景2的延续场景,评审人在PingCode的通知下前往GitHub/GitLab中进行Code Review,在他给出Review结果之后,开发者会第一时间收到PingCode的通知。

场景4:当GitHub的PR(GitLab的MR)合并之后,PingCode自动将相关“任务”的状态设置为“已完成”。这是前3个场景的延续场景,当代码合入主分支之后,这个开发任务也就自动完成了。

场景5:在GitHub/GitLab中创建分支时,自动将“工作项”状态设置为“开发中”状态。这是场景1的一种替换场景,它适用于工作项早就存在,例如:已经在看板中流动着。而到了开发阶段,在对应的代码仓库中创建一个名为“XXX/#{工作项编号}”的分支时,PingCode就会自动将#{工作项编号}对应的工作项状态设置为“开发中”,让开发阶段的开发活动和任务卡片“关联起来”。这个场景可以和场景2、3、4无缝衔接。

连接GitHub和GitLab

在使用上述功能之前,需要先让PingCode连接到GitHub/GitLab,GitHub的连接过程是:

  1. 在编辑一个规则时,点击GitHub的触发器或者动作 -> 点开“连接”的下拉框 -> 创建一个新连接。

2.  在弹出的页面中,选择将PingCode Flow for GitHub安装在哪个账号下:

3.  在接下来的页面中选择将PingCode Flow for GitHub安装在哪个仓库中:

4.  点击“Install & Authorize”即可完成连接。

这样,当刚才选中的代码仓库中“PR Review”状态变更时(还有其他的操作),PingCode就可以自动触发规则。

接下来是连接GitLab:

  1. 进入Flow -> 连接器 -> GitLab连接器中:

2. 点击“连接” -> “新建连接”:

3. 顺序填写。PingCode IP地址是方便使用者添加网络白名单时使用的;连接名称没有要求;GitLab Personal Access Token需要按要求获取,如果Token错误将无法保存成功;如果是私有部署的GitLab,那么GitLab类型选择Self Managed;GitLab访问地址需要填写公网可以访问的http地址(或者PingCode为私有部署时,PingCode所在服务器能够识别的GitLab域名地址);Webhook类型为全局时,部分GitLab触发器无法使用,但是方便管理,Webhook类型为指定项目时,全部GitLab触发器都可以使用,但是当未来新增GitLab项目时,这里需要更新一次。

4. 保存并开始使用

以上就是GitHub和GitLab的相关介绍。

新增3个重要动作

  1. 通过工作项编号获取多个工作项
  2. 过滤工作项
  3. 通过用户名查找多个用户

在任意文本类型的数据中,如果文本内容中有 #{工作项编号} 这样的数据,那么在之后都可以使用「通过工作项编号获取多个工作项」这个动作。设置该动作的来源为“来自其他步骤”,选择指定的步骤,选择这个步骤中文本类型的数据。该自动会自动解析这个文本数据中的工作项编号,然后获取到相关的工作项,在后续的动作中都可以对这些工作项进行操作。

这时有些工作项满足条件,有些可能不满足情况。我们可以通过「过滤工作项」过滤出正确的工作项:

「过滤工作项」支持绝大多数工作项属性和自定义属性,它的配置方式和“工作项属性条件”几乎一样,但是它们俩有本质的区别:「过滤工作项」的本质是过滤,由原来10个工作项过滤为5个,然后继续操作;“属性条件”的本质是判断,如果满足就接续执行,如果不满足就不再继续执行。因此根据实际需要选择自己需要的步骤。

「通过用户名查找多个用户」的用法类似于「通过工作项编号获取多个工作项」。如果文本中包含@用户名(或者@昵称),那么该动作将查找到相关的用户。

但是查出的这些人,并不是要对这些人做什么操作,而是在后续的动作中,将这些人作为动态数据进行引用。例如我们可以在评论中@这些人。

在PingCode Flow中,凡是叫做“查找”的动作,都不会改变操作对象本身,而是获取一些新的数据供其他其他步骤进行动态数据的引用。例如:「查找工作项所在项目、「查找父工作项」、「通过用户名查找多个用户」等等。而叫做“获取”的动作,一般都会改变操作对象本身,比如:「获取子工作项」、「获取父工作项」、「通过工作项编号获取多个工作项」等等。它们改变了操作对象之后,在后续的动作中再设置某个属性时,是为新的操作对象设置的,而不是为当时触发规则的对象设置的。

好了,这次的版本日志就是这些。