一、门禁功能介绍

1. 门禁功能

openEuler社区代码均托管在gitee上，为了保证代码提交质量，开发者在gitee提交PR时，会自动触发门禁执行编码规范检查、构建、安装、接口变更等检查，最后将门禁检查结果返回到PR评论中，帮助开发者定位问题及maintainer检视代码。

门禁代码开源 https://gitee.com/openeuler/openeuler-jenkins

2. src-openeuler门禁检查项

2.1 门禁触发方式

首次提交PR，或评论/retest

2.2 门禁开始运行标志

开发者可通过链接查看实时门禁构建日志。

2.3 门禁检查结果

门禁基本检查项包括6项，如表1所示。接口变更检查因为子项较多，单独以一个表格显示。

2.4 检查项对应门禁代码位置

此外，门禁目前支持部分检查项（check_code_style、check_package_license、check_package_yaml_file和check_spec_file）的选择性配置，配置文件位于ac.yaml。负责检查项PR回显的代码位于gitee_comment.py

2.5 基本检查项功能描述

2.6 接口变更检查各检查项功能描述

3 openeuler门禁检查项

3.1 门禁检查项PR回显

3.2 检查项对应门禁代码位置

此外，门禁支持检查项check_openlibing和check_sca的选择性配置，配置文件位于ac.yaml。负责检查项PR回显的代码位于gitee_comment.py

当前check_openlibing、check_sca均是调用远端服务实现的。

二、 门禁结果答疑&&误报反馈

1. 门禁责任田划分

注：1. 软件包单仓门禁中的代码片段扫描（check_sca）和编码规范检查（check_code）是通过调用majun平台服务实现的

2. 软件包单仓门禁维护人员是作为openeuler以及src-openeuler单仓门禁接口人，单仓门禁问题都可以找他们；如果是obs或者是基础设施服务问题，则需要再联系相应的维护人员。常见问题及解决方案可参考门禁问题排查手册。

2. 门禁结果

如果对门禁结果有疑问或者认为门禁结果不准确，可以向相关负责人反馈问题，我们会尽快解决，无法短时间解决的可以向门禁仓库https://gitee.com/openeuler/openeuler-jenkins提issue跟踪进展。之后，您可以通过pr评论反馈门禁误报情况，这些统计数据便于我们以后能做得更好。

标记误报的评论格式为：/ci_unmistake build_no或者/ci_mistake build_no <mistake_type> <ci_mistake_stage>

注：

1. ci_mistake用于标记误报，ci_unmistake用于撤回标记，必选其一
2. build_no指的是trigger工程的构建号，门禁开始执行时会在评论中打印门禁任务链接及构建号，由于同一个pr可以有多次构建结果，因此通过构建号区分。必选参数
3. mistake_type表示误报类型。可选参数，可以选择ci,obs,infra或者不填，这里将误报结果划分为门禁本身，obs以及基础设施三类
4. ci_mistake_stage表示误报阶段。可选参数，check_binary_file, check_package_license, check_package_yaml_file, check_spec_file, check_build, check_install, compare_package, build_exception选一项或多项，也可不填，除build_exception外均与门禁检查项一一对应，而build_exception表示门禁运行异常（如门禁结果不返回）。
5. mistake_type和ci_mistake_stage的填写顺序没有要求，可以调换

三、门禁代码上线流程

依次包括3个步骤：向门禁代码仓提交并合入PR（找maintainer）；为此次提交生成tag（找maintainer）；更新容器镜像（找门禁看护人员wanghuan158, MementoMoriCheng。少数情况下需要门禁看护人员修改jenkins配置。

1. 提交并合入PR

门禁代码放在https://gitee.com/openeuler/openeuler-jenkins，找maintainer合入代码。

2. 生成tag

理论上每次提交，均可以生成tag（tag相比于commit号，更易读）；一般情况下，不是每个PR合入都是需要立即上线的，因此不必每个commit均生成一个tag。

3. 生成容器镜像

目前门禁代码机器环境已经放到了容器镜像中，因此每次更新门禁代码时均需要更新容器镜像代码才能生效，镜像版本通过tag区分。

四、运行节点定制

1. 当前节点/镜像列表

下表列出了与门禁相关的节点：

注：1. 当前src-openeuler全部门禁工程、openeuler中trigger和comment工程，全部代码有门禁侧统一配置，使用环境相同，因此节点固定

2.openeuler中x86-64和aarch64构建工程执行的代码是相关sig组自行管理的，使用的环境各不相同，节点可在加粗部分自由选择，请不要使用其他节点，以免干扰其他jenkins任务的功能

2. 节点定制

部分任务可能需要定制门禁运行节点。

2.1 基础镜像缺乏依赖包，运行时安装比较耗时

门禁提供的容器环境是可以在运行时安装依赖包的，因此少量依赖包建议直接在运行脚本中使用sudo yum install -y xxx安装。当缺乏的依赖包比较多时，则建议向门禁仓库https://gitee.com/openeuler/openeuler-jenkins提交一个dockfile，由门禁侧检视合入后重新制作镜像，并创建一个新的运行节点。

dockerfile格式可参考https://gitee.com/openeuler/openeuler-jenkins/blob/master/src/dockerfile/release-tools-dockerfile, 通常只需要修改前两条语句即可：

FROM swr.cn-north-4.myhuaweicloud.com/openeuler/openjdk/OPENJDK:TAG
RUN set -eux; \
    yum install -y python3-pip cpio bsdtar expect openssh sudo vim git strace python-jenkins python3-requests python-concurrent-log-handler python3-gevent python3-marshmallow python3-pyyaml python-pandas python-xlrd python-retrying python-esdk-obs-python git 

2.2 基础镜像版本不是openeuler

此时除了编写dockerfile外，还需要提供对应版本的基础镜像。

2.3 机器架构不符合要求

在前面的基础上还需要额外提供对应架构的机器，然后完成步骤2.2和2.1，此时门禁代码需要做适配。