门禁功能指导手册

zhengyaohui2022-03-21门禁openeulersrc-openeuler

一、门禁功能介绍

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_binary_file二进制文件检查check_binary_file.py
check_package_licenselicense合法性检查check_spec.pyLicenses.yaml
check_package_yaml_fileyaml文件格式检查check_yaml.pycheck_repo.py
check_spec_filespec文件格式检查check_spec.py
check_consistency源码文件一致性检查check_consistency.py
check_build包构建osc_build_k8s.py
check_install验证构建出的包能否安装extra_work.py
compare_package接口变更检查compare_package.py

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

check_package_license是调用远端服务(https://compliance3.openeuler.org/sca)实现的,如果报存在非OSI/FSF认证的License,可以参考 License准入列表 https://compliance.openeuler.org/license-list, 若需对License发起准入申请,请联系合规SIG组或chenyixiong3@huawei.com

2.5 基本检查项功能描述

检查项功能SUCCESSFAILEDWARNING
check_binary_file检查仓库中是否存在二进制文件不存在以.pyc、.jar、.ko、.o为后缀的文件(包括压缩包内,但不包括以链接形式给出的上游社区)不符合SUCCESS的情况不涉及
check_package_license检查license合法性全部为白名单,并且源码和spec描述的license保持一致存在黑名单license全部为白名单,但是源码和spec描述的license不一致
check_package_yaml_file检查yaml格式version_control、src_repo、tag_prefix、seperator字段完整,并且version_control字段内容与spec文件中url对应的域名一致不符合SUCCESS的情况不涉及
check_spec_file检查sepc合法性版本号不变时,release号必须递增;版本号变化时,release必须置为1;补丁在编译时必须全部应用;changelog格式正确不符合SUCCESS的情况不涉及
check_consistency通过远端和本地源码文件的sha256值是否一致来判断源码包是否发生变更远端和本地源码文件的sha256值一致不符合SUCCESS的情况不涉及
check_build验证编译构建rpm包成功不符合SUCCESS的情况不涉及
check_install验证安装成功安装构建出的rpm包不符合SUCCESS的情况不涉及

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

检查项功能SUCCESSFAILEDWARNING
add_rpms检查PR是否新增rpm包相比于同分支上一个成功合入pr,无新增rpm包不符合SUCCESS的情况不涉及
delete_rpms检查PR是否删除rpm包相比于同分支上一个成功合入pr,无删除rpm包不符合SUCCESS的情况不涉及
kabi检查PR内核abi是否变化相比于同分支上一个成功合入pr,内核abi无变化不符合SUCCESS的情况不涉及
drive_kabi检查PR内核驱动abi是否变化相比于同分支上一个成功合入pr,内核驱动abi无变化不符合SUCCESS的情况不涉及
kconfig检查PR内核配置是否变化相比于同分支上一个成功合入pr,内核配置无变化不符合SUCCESS的情况不涉及
drive_kconfig检查PR内核驱动配置是否变化相比于同分支上一个成功合入pr,内核驱动配置无变化不符合SUCCESS的情况不涉及
ko检查PR内核驱动模块是否变化相比于同分支上一个成功合入pr,驱动模块无变化不符合SUCCESS的情况不涉及
rpm_files检查PR生成的rpm包是否删除普通文件相比于同分支上一个成功合入pr,每个rpm的文件列表无删减(不检查文件变化)不符合SUCCESS的情况不涉及
rpm_provides检查PR生成的rpm包提供的组件名是否变化相比于同分支上一个成功合入pr,每个rpm提供的组件名称无变化,无增删组件不符合SUCCESS的情况不涉及
rpm_requires检查PR生成的rpm包依赖组件名是否变化相比于同分支上一个成功合入pr,每个rpm依赖的组件名称无变化,无增删依赖不符合SUCCESS的情况不涉及
rpm_abi检查PR生成的rpm包二进制接口是否变化(C++)相比于同分支上一个成功合入pr,每个rpm的二进制接口无变化不符合SUCCESS的情况不涉及
rpm_jabi检查PR生成的rpm包二进制接口是否变化(Java)相比于同分支上一个成功合入pr,每个rpm的jabi无变化不符合SUCCESS的情况不涉及
rpm_cmd检查PR生成的rpm包命令文件是否有变化相比于同分支上一个成功合入pr,每个rpm的命令文件无变化不符合SUCCESS的情况不涉及
rpm_config检查PR生成的rpm包配置文件是否有变化相比于同分支上一个成功合入pr,每个rpm的配置文件无变化不符合SUCCESS的情况不涉及
rpm_header检查PR生成的rpm包头文件是否有变化相比于同分支上一个成功合入pr,每个rpm的头文件无变化不符合SUCCESS的情况不涉及
rpm_service检查PR生成的rpm包服务文件是否有变化相比于同分支上一个成功合入pr,每个rpm的服务文件无变化不符合SUCCESS的情况不涉及
rpm_lib检查PR生成的rpm包库文件是否有增删相比于同分支上一个成功合入pr,每个rpm的库文件无增删变化不符合SUCCESS的情况不涉及
rpm_symbol检查本次PR符号变化是否影响到其它包相比于同分支上一个成功合入pr,本次pr不影响到其它包不符合SUCCESS的情况不涉及

2.7 接口变更差异信息issue提交

PR接口变更检查的差异信息将以issue形式提交至对应仓库(针对L0-L2软件包),并关联到分支对应长生命周期里程碑。PR提交者可对差异信息check,对检查差异项进行修改至确认PR提交没有产生兼容性变更影响后,由maintainer审核确认后可合入PR。

3 openEuler 门禁检查项

3.1 门禁检查项 PR 回显

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

检查项功能描述主要代码位置
check_code编码规范检查check_code.py
check_sca代码片段扫描check_sca.py
check_package_licenselicense合法性检查check_openeuler_license.py
x86-64/仓库名x86-64环境下包构建及构建后检查维护者自行实现,不属于门禁代码
aarch64/仓库名aarch64环境下包构建及构建后检查同上

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

当前check_openlibing是调用远端服务(https://majun.osinfra.cn:8384/api/openlibing/codecheck)实现的;check_sca是调用远端服务(https://sca-beta.osinafra.cn)实现的;check_package_license则是调用远端服务(https://compliance3.openeuler.org/sca)实现的。

3.3 仓库增加PR门禁功能

openeuler下仓库想要加入pr门禁,需要在门禁代码仓库提交pr并合入,可参考文档 创建门禁工程

3.4 仓库增加sca或者codecheck检查

openeuler下仓库想要增加sca或者codecheck检查,需要在门禁代码仓中修改静态检查配置文件,在allow_list中添加对应仓库,并提交pr合入即可。

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

1. 门禁责任田划分

责任田Maintainer
门禁总接口人wanghuan158
community仓库维护人员georgecao, liuqi469227928, dakang_siji
obs_meta仓库维护人员dongjie110
release_management仓库维护人员dongjie110
软件包单仓门禁维护人员wanghuan158,
基础设施维护(包括obs、gitee、jenkins基础服务,也包括硬件和网络)人员georgecao, liuqi469227928, dakang_siji
obs工程维护人员wangchong1995924, small_leek
EulerMaker工程维护人员caoxueliang, small_leek
majun维护人员openlibing@163.com

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

  1. 软件包单仓门禁维护人员是作为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)。少数情况下需要门禁看护人员修改jenkins配置。

1. 提交并合入PR

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

2. 生成tag

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

3. 生成容器镜像

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

四、运行节点定制

1. 当前节点/镜像列表

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

节点工程
k8s-x86-soe和k8s-aarch64-soesrc-openeuler全部门禁工程
k8s-x86-oeopeneuler中trigger和comment工程
k8s-x86-openeuler、k8s-x86-openeuler-20.03-lts、k8s-x86-openeuler-20.03-lts-sp1、k8s-x86-openeuler-20.03-lts-sp2、k8s-x86-openeuler-20.03-lts-sp3、k8s-x86-openeuler-20.09、k8s-x86-openeuler-21.03、k8s-aarch64-openeuler、k8s-aarch64-openeuler-20.03-lts、k8s-aarch64-openeuler-20.03-lts-sp1、k8s-aarch64-openeuler-20.03-lts-sp2、k8s-aarch64-openeuler-20.03-lts-sp3、k8s-aarch64-openeuler-20.09、k8s-aarch64-openeuler-21.03openeuler中x86-64和aarch64构建工程

注: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,此时门禁代码需要做适配。


【免责声明】本文仅代表作者本人观点,与本网站无关。本网站对文中陈述、观点判断保持中立,不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考,由此产生的所有法律责任均由读者本人承担。