CI 门禁流程

门禁流程

当开发者(contributor)向OpenCloudOS Stream的软件仓库首次发起Pull request时，门禁CI会对该Pull request进行一系列检查，确保其符合OCS软件包合入的的标准。门禁CI大致会经历如下阶段：

门禁CI自动检查阶段
contributor确认阶段（需要PR发起人参与）
测试重编阶段（若有）
Maintainer确认阶段（需要Maintainer审核最终结论）
PR后处理阶段

需要contributor负责的阶段主要是：contributor确认阶段

需要Maintainer负责的阶段主要是：测试重编阶段 + Maintainer确认阶段 + PR后处理阶段

整体的流程图如下所示：

各阶段详情

门禁CI自动检查阶段

该阶段会在开发者(contributor)向OpenCloudOS Stream的软件仓库首次发起Pull request后自动执行，或者在任意阶段评论/retest，触发执行。主要完成如下检查：

spec文件检查：主要检查version, release, 以及changelog是否合规
编译构建检查：利用koji完成不同架构的的编译构建
安装检查：将编译好的rpm软件包，进行安装测试
兼容性检查：从如下指标，检查升级后的软件包相对于当前的是否有兼容性变化
- 子包数目(subrpmlist)是否变化？
- 是否增删文件(filelist)？
- 原本提供/需求的能力(ability)是否发生变化？
- abi是否发生改变？
- api是否发生改变？
- 可执行文件(excutable)的输出是否发生改变？
- 配置文件(conf)是否发生改变？

门禁扫描结果如图所示：（其中备注栏为提示信息，告知开发者问题原因，详细需查看对应检查项的日志）

contributor确认阶段

若编译安装检查无FAILED项目，再完成兼容性检查各项后（兼容性检查各项出现FAILED不会影响流程推进），会自动流转到contributor确认阶段，如图所示：

该阶段的主要目的是为了让开发者审核CI的兼容性检查结果和确认兼容性结论。如果你仔细比对代码后，确认兼容性检查某项有误，可以评论disagree <item>（例如：不认为excutable发生改变，或者excutable的改变不能引发兼容性变化，评论disagree excutable）; 当然如果你认为某项实际兼容性发生了改变，但是CI没有检查出来，同样可以评论disagree <item>

温馨提示：agree和disagree并不会阻碍后续PR的合入，该阶段是为了人工确认各项兼容性是否改变，从而决定后续哪些软件包需要在当前PR合入后，基于该软件包进行重编，以确保该包兼容性改变后，系统依旧稳定

AI辅助检查

CI门禁能够检查出哪些检查项出现变更，但有时候出现变更不一定等于兼容性发生变化！由此我们引入AI，辅助开发者判断，如图所示

测试重编阶段

contributor确认兼容性检查结果后，CI门禁会根据各兼容性检查项结论，去寻找需要基于此进行测试/正式重编的软件包，判断原则如下：

测试重编包的来源：
- 1.兼容性发生改变，该包（B）可能需要基于升级后的软件包（A）重编，需要测试重编进一步确认
- 2.该包（B）编译过程的check（测试）阶段用到了软件包（A），尽管兼容性无改变，但某些行为的变化会导致check阶段失败
正式重编包来源：
- 1.兼容性发生改变，确认该包（B）受到影响，必须基于升级后的软件包（A）重编
- 2.测试重编失败的包，也会加入到正式重编

测试重编会在当前阶段进行，直到所有软件包测试重编结束，才会自动流转到下一阶段。