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

by sunjingyun

主要更新内容：

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

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