diff --git "a/CESHI_ZHUANYONG/CI\345\217\212\344\273\243\347\240\201\351\227\250\347\246\201/\346\227\245\345\277\227\346\226\207\344\273\266/710/CI-META\344\273\223\345\272\223\351\205\215\347\275\256\350\247\204\350\214\203.md" "b/CESHI_ZHUANYONG/CI\345\217\212\344\273\243\347\240\201\351\227\250\347\246\201/CI-META\344\273\223\345\272\223\351\205\215\347\275\256\350\247\204\350\214\203.md"
similarity index 35%
rename from "CESHI_ZHUANYONG/CI\345\217\212\344\273\243\347\240\201\351\227\250\347\246\201/\346\227\245\345\277\227\346\226\207\344\273\266/710/CI-META\344\273\223\345\272\223\351\205\215\347\275\256\350\247\204\350\214\203.md"
rename to "CESHI_ZHUANYONG/CI\345\217\212\344\273\243\347\240\201\351\227\250\347\246\201/CI-META\344\273\223\345\272\223\351\205\215\347\275\256\350\247\204\350\214\203.md"
index 88045c5d97ac44d85ced71eae46b8fbfe0f14613..dff6cb92f9f58f5f9bfa02383c0563be6200cc31 100644
--- "a/CESHI_ZHUANYONG/CI\345\217\212\344\273\243\347\240\201\351\227\250\347\246\201/\346\227\245\345\277\227\346\226\207\344\273\266/710/CI-META\344\273\223\345\272\223\351\205\215\347\275\256\350\247\204\350\214\203.md"
+++ "b/CESHI_ZHUANYONG/CI\345\217\212\344\273\243\347\240\201\351\227\250\347\246\201/CI-META\344\273\223\345\272\223\351\205\215\347\275\256\350\247\204\350\214\203.md"
@@ -2,18 +2,118 @@
# 简介
[CI-META仓库](https://gitee.com/anolis/ci-meta)做为OpenAnolis社区PackageCI测试流程的配置中心，提供了全局配置和自定义配置，全局配置默认对Gitee上的OpenAnolis企业账户下的所有仓库生效，自定义配置允许开发者通过自定义形式接入社区测试流程，本文主要介绍CI-META仓库配置规范。
-加点信息
-
+# 目录结构
+仓库由三个全局yaml配置和一个自定义目录组成，全局配置无需开发者参与，默认生效，自定义目录允许开发者根据自身需要自定义测试配置，如果开发者对某个仓库配置了自定义测试，则不在运行全局配置的测试。
+```json
+├── products.yaml #定义产品规范和匹配分支
+├── toneconfs.yaml #定义公共测试用例
+├── globals.yaml #定义官方仓库全局配置
+├── repos #自定义目录
+│ ├── a #软件包索引目录
+│ ├── b
+│ ├── c
+│ │ ├── cmake #软件包名称
+│ │ │ ├── ci.yaml #官方仓库自定义配置
+│ │ │ ├── test.sh #官方仓库自定义脚本
+│ │ └── cxxxx
+│ ├── d
+│ └── ....
+```
+
+# 全局配置
+
+## products.yaml
+产品配置文件，用于创建任务和筛选子模块配置。
+```yaml
+products:
+ Anolis23: #产品名称
+ short_name: an23 #产品名缩写，用于创建测试任务
+ branch: ['a23'] #匹配分支，分支中包含branch，则匹配成功
+ Anolis8:
+ short_name: an8
+ branch: ['a8']
+ default: True #默认产品配置
+ Anolis7:
+ short_name: an7
+ branch: ['a7']
+ Anolis8.4:
+ short_name: an8.4
+ branch: ['a8.4']
+ Anolis8.2:
+ short_name: an8.2
+ branch: ['a8.2']
+ Anolis7.9:
+ short_name: an7.9
+ branch: ['a7.9']
+ Anolis7.7:
+ short_name: an7.7
+ branch: ['a7.7']
+```
+
+## toneconfs.yaml
+公共测试用例配置文件，可以在globals.yaml和ci.yaml中引用。
+```yaml
+basic_test:
+ tone_workspace: packageci
+ tone_project: Anolis_Packages
+ tone_test_suite: anolis-ci-test
+ tone_test_conf: group=basic_test
+ tone_test_case: check_license,check_specfile,check_codestyle
+rpm_test:
+ tone_workspace: packageci
+ tone_project: Anolis_Packages
+ tone_test_suite: anolis-ci-test
+ tone_test_conf: group=rpm_test
+ tone_test_case: pkg_smoke_test,check_abi_diff,check_pkg_dependency
+custom_test:
+ tone_workspace: packageci
+ tone_project: Anolis_Packages
+ tone_test_suite: anolis-ci-test
+ tone_test_conf: group=custom_test
+ tone_test_case: custom_script
+```
## globals.yaml
全局配置文件，指明组织仓库运行的测试任务和任务运行方式。
-
+```yaml
+src-anolis-os: #仓库所属组织名称
+ code_test: #任务名称
+ tone_test: basic_test #任务配置，来自公共测试用例配置文件
+ server_config: '{product}-anck-x86_64' #任务运行机器配置，product为产品配置
+ abs_build:
+ type: abs #任务类型，默认为tone
+ integration_test:
+ depend: [abs_build] #依赖任务，如果依赖任务失败，则不允许本任务
+ tone_test: rpm_test
+ server_config: #支持不同规格服务器
+ x86_64: '{product}-anck-x86_64'
+ aarch64: '{product}-anck-aarch64'
+ parallel: #任务运行方式，由上到下串行执行
+ - code_test, abs_build #同一层并行执行
+ - integration_test
+```
# 自定义配置
+## ci.yaml
+当全局配置不能满足某个仓库的测试需求时，可以通过配置repos中的ci.yaml来接入自定义配置，ci.yaml中分为仓库配置，测试配置，通知配置。
+
+### 仓库配置
+```yaml
+#pr，即提交pr就会触发测试，支持gitee平台和github平台
+repo:
+ git_url: https://gitee.com/anolis/ci-meta.git
+ trigger_mode: pr
-
+#pull，定时监测指定仓库分支的commit，如果变化则触发测试
+repo:
+ git_url: https://gitee.com/anolis/ci-meta.git
+ git_branch: master
+ trigger_mode: pull
+ trigger_time: * * * * * #crontab风格时间表达式
+```
+
### 测试配置
```yaml
#示例1，引用全局配置
@@ -31,7 +131,17 @@ test:
server_config: {product}-anck-x86_64
#示例3，自定义测试配置
+test:
+ test_task_3:
+ tone_test: keentune
+ keentune:
+ tone_workspace: keentune
+ tone_project: keentune
+ tone_test_suite: keentune
+ tone_test_conf: default
+ server_config: {product}-anck-x86_64
+#示例4，自定义脚本配置
test:
test_task_4:
tone_test: script
@@ -49,6 +159,18 @@ test:
parallel:
- test_task_5, test_task_6
+#示例6，运行串行测试任务
+test:
+ test_task_7:
+ tone_test: basic_test
+ server_config: {product}-anck-x86_64
+ test_task_8:
+ tone_test: basic_test
+ server_config: {product}-anck-aarch64
+ parallel:
+ - test_task_7
+ - test_task_8
+
#示例8，扩展T-One配置
test:
test_task_8:
diff --git "a/CESHI_ZHUANYONG/CI\345\217\212\344\273\243\347\240\201\351\227\250\347\246\201/\345\206\205\346\240\270\344\273\243\347\240\201\351\227\250\347\246\201\347\263\273\347\273\237\344\275\277\347\224\250\346\214\207\345\215\227.md" "b/CESHI_ZHUANYONG/CI\345\217\212\344\273\243\347\240\201\351\227\250\347\246\201/\345\206\205\346\240\270\344\273\243\347\240\201\351\227\250\347\246\201\347\263\273\347\273\237\344\275\277\347\224\250\346\214\207\345\215\227.md"
new file mode 100644
index 0000000000000000000000000000000000000000..759823a010ff6ecbae26fb515c0c3e660ed42026
--- /dev/null
+++ "b/CESHI_ZHUANYONG/CI\345\217\212\344\273\243\347\240\201\351\227\250\347\246\201/\345\206\205\346\240\270\344\273\243\347\240\201\351\227\250\347\246\201\347\263\273\347\273\237\344\275\277\347\224\250\346\214\207\345\215\227.md"
@@ -0,0 +1,67 @@
+
+# 背景介绍
+龙蜥操作系统内核代码已经在Gitee上正式开源，与此同时，内核代码门禁系统也同步启用，并向社区开发者提供两种模式的代码检查，以保障龙蜥内核代码质量的稳定性和可靠性。更多内核代码开发流程，请参考[Cloud Kernel开发流程](https://gitee.com/anolis/cloud-kernel/wikis/Cloud%20Kernel%20%E5%BC%80%E5%8F%91%E6%B5%81%E7%A8%8B)。
+
+# PR 模式
+开发者fork内核代码仓库，并在本地进行开发，向内核代码仓库提交代码合入请求，即PR请求时，会自动触发代码门禁检查流程，并由社区机器人通过评论方式实时反馈流程进度，开发者可根据机器人的回复，在PR中评论相应的命令，以推进流程继续，直至通过评审和测试，最终合入内核代码仓库。
+
+## CLA检查
+每当有新的PR提交时，代码门禁首先检查PR提交者的贡献者协议（CLA协议）签署情况，如果已签署，则会自动进入代码测试流程，并在PR中打上anolis_cla_pass，anolis_testing两个标签；如果未签署，则会在PR中打上anolis_cla_fail标签，并评论PR提示提交者未签署CLA协议。
当开发者签署CLA协议之后，可以在所提交的PR中评论/check-cla重新检查协议签署情况，如果通过，则会把anolis_cla_fail标签修改为anolis_cla_pass标签，并评论PR提示开发者后续操作；如果未签署，则会评论PR提示提交者未签署CLA协议。
评论/check-cla不会触发测试流程。
+
+## 代码测试
+如果开发者已签署CLA协议，则在提交新的PR时自动触发代码测试流程，开发者可关注PR标签，存在anolis_testing则表示目前该PR正在进行代码测试，当测试完成之后，会把测试结果和详细结果链接一起评论到PR中，并根据测试结果修改anolis_testing标签，测试成功将标签修改为anolis_test_pass，测试失败将标签修改为anolis_test_fail。
开发者可以评论/retest重新进入代码测试流程，前提是CLA检查通过或者测试失败。同时，当机器人检测到PR中的代码发生了变化时，会重置当前测试状态，无论成功还是失败。如果在代码测试流程中更新了提交的代码，会增加code_update标签，当测试完成后，无论成功失败，本次测试结果均为失败。
maintainer可以评论/skip-test帮助开发者跳过某些可以忽略测试失败的场景。
目前线上测试机数量较少，且均为虚拟机，编译速度较慢，请开发者耐心等待。
+
+## 自动合入
+当PR的测试通过时，即标签中存在anolis_test_pass时，需要maintainer对PR进行review，如果review不通过，需要开发者根据maintainer的提示修改代码，并重新触发测试，修改commit log和PR文本等不修改代码的行为，不需要重新触发测试。
当review通过之后，相关review的人员可以在评论中回复自己的RVB签名，由maintainer评论/merge进行自动何如。自动合入首先检查当前PR中的所有签名信息，按照规则进行排列，然后合入PR，在本地代码中更新，对新合入的代码进行签名添加和PR链接添加，上述流程全部成功之后，本次PR才算合入完成。
+
+# 自助模式
+开发者fork内核代码仓库，并在本地进行开发，无需提交PR也可使用代码门禁的自助检测模式对已开发的代码进行检测，自助模式没有CLA检查和签名检查，仅触发代码测试流程，能够帮助开发者提前了解代码质量情况和问题。
使用社区帐号登录[CBC](https://cbc.openanolis.cn)，点击创建任务，首先选择fork仓库的源分支，然后将默认的代码仓库和代码分支修改为开发者自己的仓库和分支，其余选项可按照自身需求进行选择，最后点击确定即可进入代码测试流程，等待执行完毕，即可点击查看，跳转到任务详情页，查看详细的执行日志。
由于测试资源紧张，每位开发者仅允许创建两个执行的任务（一个x86一个arm，也可以两个x86任务），需等待之前提交的任务完成之后才能再次提交新的任务，每次检测提交的commit个数不能超过50个。
+
+# 附录
+
+## 命令说明
+| 回复命令 | 功能 | 可使用人员 |
+| --- | --- | --- |
+| /check-cla | 检查PR提交者签署CLA协议情况 | PR提交者，openanolis企业成员 |
+| /retest | 重新进入代码测试流程 | PR提交者，openanolis企业成员 |
+| /skip-test | 跳过代码测试流程 | maintainer |
+| /merge | 进行代码合入 | maintainer |
+
+
+## 标签说明
+| 标签 | 说明 |
+| --- | --- |
+| anolis_cla_pass | PR提交者已签署CLA协议 |
+| anolis_cla_fail | PR提交者未签署CLA协议 |
+| anolis_testing | 代码测试中 |
+| code_update | 代码测试中发生了代码更新 |
+| anolis_test_pass | 代码测试通过 |
+| anolis_test_fail | 代码测试未通过 |
+| anolis_merge_pass | 自动合入通过 |
+| anolis_merge_fail | 自动合入未通过 |
+
+
+## 检测说明
+| 检测项 | 检测目标 | 检测范围 |
+| --- | --- | --- |
+| review检测 | 检查每个commit log是否包含规范字段，例如#ANBZ等 | 每一个commit |
+| checkpatch检测 | 与上游社区的checkpatch检测保持一致，范围根据情况有一定适配 | 每一个龙蜥自研的commit |
+| build检测 | anolis_defconfig | 每一个commit，区分aarch64与x86_64 |
+| kconfig检测 | 检测所有的config文件是否有新的config选项未设置，防止编译出错 | 只检测所有提交中的最后一个commit，区分aarch64与x86_64 |
+| 全量build检测 | allnoconfig，allyesconfig，defconfig，anolis_defconfig，anolis-debug_defconfig | 只检测所有提交中的最后一个commit，区分aarch64与x86_64 |
+| 启动检测 | 检测PR代码所构建出的内核rpm安装之后能否正常启动 | 只检测所有提交中的最后一个commit，区分aarch64与x86_64 |
+
+
+
+## checkpatch规则
+| 包含anolis自研前缀 | 修改内核配置 | 来自upstream | 检查checkpatch |
+| --- | --- | --- | --- |
+| 是 | 是 | 是（warning提示） | 是 |
+| 是 | 是 | 否 | 是 |
+| 是 | 否 | 是（warning提示） | 是 |
+| 是 | 否 | 否 | 是 |
+| 否 | 是 | 是（warning提示） | 否 |
+| 否 | 是 | 否 | 否 |
+| 否 | 否 | 是 | 否 |
+| 否 | 否 | 否（error报错） | 否 |
+
diff --git "a/CESHI_ZHUANYONG/CI\345\217\212\344\273\243\347\240\201\351\227\250\347\246\201/\346\227\245\345\277\227\346\226\207\344\273\266/\346\265\213\350\257\225\346\226\207\344\273\266.md" "b/CESHI_ZHUANYONG/CI\345\217\212\344\273\243\347\240\201\351\227\250\347\246\201/\346\227\245\345\277\227\346\226\207\344\273\266/\346\265\213\350\257\225\346\226\207\344\273\266.md"
deleted file mode 100644
index 09d06d136ac6832c28088e69a94f2b40921996ad..0000000000000000000000000000000000000000
--- "a/CESHI_ZHUANYONG/CI\345\217\212\344\273\243\347\240\201\351\227\250\347\246\201/\346\227\245\345\277\227\346\226\207\344\273\266/\346\265\213\350\257\225\346\226\207\344\273\266.md"
+++ /dev/null
@@ -1,61 +0,0 @@
-```yaml
-#示例1，引用全局配置
-test:
- test_task_1:
- tone_test: basic_test
- server_config: {product}-anck-x86_64
-
-#示例2，覆盖全局配置
-test:
- test_task_2:
- tone_test: basic_test
- basic_test:
- tone_test_case: check_license,check_specfile
- server_config: {product}-anck-x86_64
-
-#示例3，自定义测试配置
-test:
- test_task_3:
- tone_test: keentune
- keentune:
- tone_workspace: keentune
- tone_project: keentune
- tone_test_suite: keentune
- tone_test_conf: default
- server_config: {product}-anck-x86_64
-
-#示例5，运行并行测试任务
-test:
- test_task_5:
- tone_test: basic_test
- server_config: {product}-anck-x86_64
- test_task_6:
- tone_test: basic_test
- server_config: {product}-anck-aarch64
- parallel:
- - test_task_5, test_task_6
-
-#示例6，运行串行测试任务
-test:
- test_task_7:
- tone_test: basic_test
- server_config: {product}-anck-x86_64
- test_task_8:
- tone_test: basic_test
- server_config: {product}-anck-aarch64
- parallel:
- - test_task_7
-
-#示例8，扩展T-One配置
-test:
- test_task_8:
- tone_test: basic_test
- basic_test:
- tone_test_case: check_license,check_specfile
- server_config: {product}-anck-x86_64
- tone_extend: #详细参数请参考 T-One API
- need_reboot: 1
- script_info:
- - pos: before
- script: sleep 10
-```
\ No newline at end of file
diff --git "a/CESHI_ZHUANYONG/CI\345\217\212\344\273\243\347\240\201\351\227\250\347\246\201/\351\276\231\350\234\245\345\206\205\346\240\270CI\346\234\215\345\212\241-KernelCI.md" "b/CESHI_ZHUANYONG/CI\345\217\212\344\273\243\347\240\201\351\227\250\347\246\201/\351\276\231\350\234\245\345\206\205\346\240\270CI\346\234\215\345\212\241-KernelCI.md"
new file mode 100644
index 0000000000000000000000000000000000000000..37557cb85194881c190a6f17712a06f5d1e7aa33
--- /dev/null
+++ "b/CESHI_ZHUANYONG/CI\345\217\212\344\273\243\347\240\201\351\227\250\347\246\201/\351\276\231\350\234\245\345\206\205\346\240\270CI\346\234\215\345\212\241-KernelCI.md"
@@ -0,0 +1,85 @@
+
+# 服务介绍
+为保障龙蜥社区内核代码的质量，每当有新的内核代码仓库代码合入请求，即PR请求时，都会自动触发bot里的KernelCI流程（内核代码门禁系统），并由bot通过评论方式实时反馈流程进度，开发者可根据bot的回复，在PR中评论相应的命令，以推进流程继续，直至通过评审和测试，最终合入内核代码仓库。更多内核代码开发流程，请参考[Cloud Kernel开发流程](https://openanolis.cn/sig/Cloud-Kernel/doc/607596680293474815)。
+
+# PR 规范
+
+- 内核CI服务仅支持龙蜥社区官方[内核仓库](https://gitee.com/anolis/cloud-kernel)，及其它已被管理员审批的内核仓库。
+- 向内核仓库提交PR，请遵守[社区规范](https://openanolis.cn/sig/Cloud-Kernel/doc/607605992881480196)。
+- 为保证PR review质量，每个PR的commit数量请不要超过25个。
+
+
+# 操作流程
+
+1. 每当内核仓库有新的PR提交时，bot首先会检查PR提交者的贡献者协议（CLA协议）签署情况，如果已签署，则会自动进入代码测试流程。
+
+
+
+2. 如果未签署，则会评论PR提示提交者未签署CLA协议。
+
+
+
+3. 当开发者签署CLA协议之后，可以在PR中评论/check-cla重新检查协议签署情况，评论/check-cla不会触发测试流程，如需测试，评论/retest即可进入测试流程。
+
+
+
+4. 当测试完成之后，会把测试结果和详细结果链接一起评论到PR中。
+
+
+
+5. 如果测试失败，开发者可在修改代码之后，评论/retest重新进入代码测试流程。
+
+
+
+6. maintainer可以评论/skip-test帮助开发者跳过某些可以忽略测试失败的场景。
+7. 当代码测试通过后，需由maintainer进行review，review不通过，则请开发者按照maintainer的意见和建议进行修改，如果有代码修改，则需要评论/retest重新进行测试。
+8. 当代码测试和review均通过时，可由maintainer评论/merge进行自动合入，合入后将会对本次PR的commit进行自动签名。
+
+
+
+# 可用命令
+| 回复命令 | 功能 | 可使用人员 |
+| --- | --- | --- |
+| /check-cla | 检查PR提交者签署CLA协议情况 | PR提交者，openanolis企业成员 |
+| /retest | 重新进入代码测试流程 | PR提交者，openanolis企业成员 |
+| /skip-test | 跳过代码测试流程 | maintainer |
+| /merge | 进行代码合入和自动签名 | maintainer |
+
+
+# 标签说明
+每次bot操作均会在PR上打上状态标签，开发者可根据标签信息判断当前流程，并进行后续操作：
+
+| 标签 | 说明 |
+| --- | --- |
+| anolis_cla_pass | PR提交者已签署CLA协议 |
+| anolis_cla_fail | PR提交者未签署CLA协议 |
+| anolis_testing | 代码测试中 |
+| code_update | 代码测试中发生了代码更新 |
+| anolis_test_pass | 代码测试通过 |
+| anolis_test_fail | 代码测试未通过 |
+| anolis_merge_pass | 自动签名成功 |
+| anolis_merge_fail | 自动签名失败 |
+
+
+# 检测项
+| 检测项 | 检测目标 | 检测范围 |
+| --- | --- | --- |
+| review检测 | 检查每个commit log是否包含规范字段，例如#ANBZ等 | 每一个commit |
+| checkpatch检测 | 与上游社区的checkpatch检测保持一致，范围根据情况有一定适配 | 每一个龙蜥自研的commit |
+| build检测 | anolis_defconfig | 每一个commit，区分aarch64与x86_64 |
+| kconfig检测 | 检测所有的config文件是否有新的config选项未设置，防止编译出错 | 只检测所有提交中的最后一个commit，区分aarch64与x86_64 |
+| 全量build检测 | allnoconfig，allyesconfig，defconfig，anolis_defconfig，anolis-debug_defconfig | 只检测所有提交中的最后一个commit，区分aarch64与x86_64 |
+| 启动检测 | 检测PR代码所构建出的内核rpm安装之后能否正常启动 | 只检测所有提交中的最后一个commit，区分aarch64与x86_64 |
+
+
+# 接入方式
+KernelCI测试服务不但为龙蜥内核提供服务，还可以开放给合作企业，为合作企业的内核仓库提供测试服务。目前主要由SIG组形式进行合作，有需要的企业可以向内核SIG组提出申请，通过后由管理员进行配置，配置好后即可生效。具体接入流程如下：
+
+1. 合作企业内核SIG组向龙蜥内核SIG组提出接入申请
+2. 需要准备的材料有：
+ - 接入门禁的仓库分支和检测版本
+ - maintainer邮箱列表
+ - 在T-One上创建本SIG组的WorkSpace
+3. 等待审批
+4. 通过后由管理员进行配置
+5. 配置完成，立即生效
diff --git "a/CESHI_ZHUANYONG/CI\345\217\212\344\273\243\347\240\201\351\227\250\347\246\201/\351\276\231\350\234\245\345\256\271\345\231\250CI\346\234\215\345\212\241-DockerCI.md" "b/CESHI_ZHUANYONG/CI\345\217\212\344\273\243\347\240\201\351\227\250\347\246\201/\351\276\231\350\234\245\345\256\271\345\231\250CI\346\234\215\345\212\241-DockerCI.md"
new file mode 100644
index 0000000000000000000000000000000000000000..32cf053a580d3edc263b74572e516e8bcf0ecf54
--- /dev/null
+++ "b/CESHI_ZHUANYONG/CI\345\217\212\344\273\243\347\240\201\351\227\250\347\246\201/\351\276\231\350\234\245\345\256\271\345\231\250CI\346\234\215\345\212\241-DockerCI.md"
@@ -0,0 +1,134 @@
+
+# 服务介绍
+为了支持龙蜥社区容器镜像的构建发布流程，bot为社区容器镜像仓库提供了基于龙蜥系统的DockerCI测试服务，每当有新的PR提交时，bot会自动检测PR中的Dockerfile文件修改，并触发ABS容器镜像构建任务，当测试镜像构建成功时，会触发T-One容器镜像测试任务，测试项包含基础镜像测试和应用镜像测试，同时还允许开发着在仓库中引入自定义测试用例，当测试和review均通过，PR将被maintainer合入，同时系统会自动将测试镜像推送至官方正式仓库。
+
+# PR 规范
+
+- 容器CI服务仅支持龙蜥社区官方[容器仓库](https://gitee.com/anolis/docker-images)，和github上的容器仓库。
+- 为保证容器发布质量，向容器仓库提交PR时，每个PR中限制最多包含一个Dockerfile文件。
+- 应用镜像Dockerfile存储目录限制为：应用名/应用版本/操作系统版本/Dockerfile，例如：nginx/1.14.1/8.6/Dockerfile。
+- 当PR中不包含Dockerfile时，不触发构建和发布流程，由maintainer自行考虑合入。
+
+
+# 操作流程
+
+1. 每当容器仓库有新的PR提交时，bot首先会检查PR提交者的贡献者协议（CLA协议）签署情况，如果已签署，则会自动进入代码测试流程。
+
+
+
+2. 如果未签署，则会评论PR提示提交者未签署CLA协议。
+
+
+
+3. 当开发者签署CLA协议之后，可以在PR中评论/check-cla重新检查协议签署情况，评论/check-cla不会触发测试流程，如需测试，评论/retest即可进入测试流程。
+
+
+
+4. 当测试完成之后，会把测试结果和详细结果链接一起评论到PR中。
+
+
+
+5. 如果测试失败，开发者可在修改代码之后，评论/retest重新进入代码测试流程，或者当有新的代码提交时，也会自动触发重新测试。
+
+
+
+6. maintainer可以评论/skip-test帮助开发者跳过某些可以忽略测试失败的场景。
+7. 当代码测试通过后，需由maintainer进行review，通过之后，可由maintainer评论/merge进行自动合入，并将测试镜像推送到正式仓库中。
+
+
+
+# 可用命令
+| 回复命令 | 功能 | 可使用人员 |
+| --- | --- | --- |
+| /check-cla | 检查PR提交者签署CLA协议情况 | PR提交者，openanolis企业成员 |
+| /retest | 重新进入代码测试流程 | PR提交者，openanolis企业成员 |
+| /skip-test | 跳过代码测试流程 | maintainer |
+| /merge | 进行代码合入 | maintainer |
+
+
+# 标签说明
+每次bot操作均会在PR上打上状态标签，开发者可根据标签信息判断当前流程，并进行后续操作：
+
+| 标签 | 说明 |
+| --- | --- |
+| anolis_cla_pass | PR提交者已签署CLA协议 |
+| anolis_cla_fail | PR提交者未签署CLA协议 |
+| anolis_testing | 代码测试中 |
+| code_update | 代码测试中发生了代码更新 |
+| anolis_test_pass | 代码测试通过 |
+| anolis_test_fail | 代码测试未通过 |
+
+
+# 检测项
+| 测试类型 | 测试项 | 描述 |
+| --- | --- | --- |
+| 启动测试 | test_container_startup | 使用被测容器镜像启动容器，检查内核、编程语言等是否符合预期 |
+| 应用容器状态检查 | test_container_basic | 启动应用容器后，检查容器的启动状态是否符合预期 |
+| 应用容器网络端口检查 | test_container_network | 启动应用容器后，检查容器的网络端口是否能正常访问 |
+| 应用容器服务检查 | test_container_service | 启动应用容器后，检查容器内的应用服务是否开启且状态正常 |
+| 应用容器进程检查 | test_container_process | 启动应用容器后，检查容器的应用进程存在且处于运行状态 |
+
+
+# 接入方式
+目前暂不支持其它类型的容器仓库接入，但是支持每个应用自定义测试用例，方便开发者进行测试使用。
+
+- 自定义测试功能接入
+
+需要在应用的Dockerfile文件的同级目录创建配置文件ci.yaml，生效优先级为：源仓库中Dockerfile同级的ci.yaml > 合入仓库中Dockerfile同级的ci.yaml > CI-META仓库中的[全局容器测试配置](https://gitee.com/anolis/ci-meta/blob/master/packages/d/docker-images/ci.yaml)，详细参数配置含义请参考CI-META仓库配置规范，以下是默认ci.yaml配置：
+```yaml
+repo:
+ git_url: https://gitee.com/anolis/docker-images
+ trigger_mode: pr
+test:
+ docker_build:
+ test_type: docker #1-6行为配置容器构建，无需修改
+ docker_base_test: #指定测试case，可按需修改
+ tone_test: base_test #测试case名称
+ base_test: #测试case详细配置
+ tone_workspace: container_ci_test #测试case工作空间
+ tone_project: default_container_ci_test #测试case项目
+ tone_test_suite: image-ci-test #测试case suite
+ tone_test_conf: group=container_startup_test #测试case conf
+ server_config: #测试case机器配置，可按需修改
+ x86_64: anolis-container-func-test-x86
+ aarch64: anolis-container-func-test-arm64
+ docker_app_test:
+ tone_test: app_test
+ app_test:
+ tone_workspace: container_ci_test
+ tone_project: default_container_ci_test
+ tone_test_suite: image-ci-test
+ tone_test_conf: group=application_container_func_test
+ server_config:
+ x86_64: anolis-container-test-x86
+ aarch64: anolis-container-test-arm64
+ parallel: #任务调度逻辑，上下串行，左右并行
+ - docker_build
+ - docker_base_test, docker_app_test
+```
+
+- 自定义测试脚本接入
+
+ci.yaml中支持接入自定义测试脚本，详细参数配置含义请参考CI-META仓库配置规范，以下是自定义测试脚本接入例子：
+```yaml
+test: #ci.yaml中的test
+ test_task: #自定义测试任务名称
+ tone_test: script #自定义测试任务类型，固定为script
+ entry: test.sh #测试脚本需要放到ci.yaml同级目录中
+ server_config: {product}-anck-x86_64 #自定义测试脚本使用机器配置
+```
+
+- 开源测试case接入
+
+如果用户将自己的测试用例贡献到开源T-One的测试用例库中，则可以在ci.yaml中直接配置测试case，具体贡献方式请参考T-One测试用例集成文档，以下是开源测试case接入例子：
+```yaml
+test: #ci.yaml中的test
+ test_task: #测试任务名称
+ tone_test: self_test #开源测试case名称
+ self_test: #开源测试case配置
+ tone_workspace: self_test #开源测试case工作空间
+ tone_project: self_test #开源测试case项目
+ tone_test_suite: self_test #开源测试case suite
+ tone_test_conf: self_test #开源测试case conf
+ server_config: {product}-anck-x86_64 #开源测试case机器配置
+```
diff --git "a/CESHI_ZHUANYONG/CI\345\217\212\344\273\243\347\240\201\351\227\250\347\246\201/\351\276\231\350\234\245\350\275\257\344\273\266\345\214\205CI\346\234\215\345\212\241-PackageCI.md" "b/CESHI_ZHUANYONG/CI\345\217\212\344\273\243\347\240\201\351\227\250\347\246\201/\351\276\231\350\234\245\350\275\257\344\273\266\345\214\205CI\346\234\215\345\212\241-PackageCI.md"
new file mode 100644
index 0000000000000000000000000000000000000000..6f62e43fc2f90ad9b0d69f4b4763e0645dd4cdbc
--- /dev/null
+++ "b/CESHI_ZHUANYONG/CI\345\217\212\344\273\243\347\240\201\351\227\250\347\246\201/\351\276\231\350\234\245\350\275\257\344\273\266\345\214\205CI\346\234\215\345\212\241-PackageCI.md"
@@ -0,0 +1,81 @@
+
+# 服务介绍
+为了扩展龙蜥操作系统的能力，增强龙蜥系统软件包的兼容度，bot为社区OS软件包和其他主流平台的软件包提供了基于龙蜥系统的PackageCI测试服务，测试项不但包含官方统一的测试用例，还允许开发者自定义测试用例，并且同时支持PR级和Nightly级的CI流程，其中PR测试默认对Gitee上的OpenAnolis企业账户下的所有仓库生效，Nightly测试或者其他主流平台则需要通过注册进行服务接入。
+
+# PR 规范
+
+- 软件包CI服务支持龙蜥社区[官方仓库](https://gitee.com/openanolis)下所有仓库接入，及其它在CI-META[配置仓库](https://gitee.com/anolis/ci-meta)中注册的软件包仓库。
+- 暂未对软件包PR做规范检查，请自觉遵守社区规范。
+
+# 操作流程
+
+## PR流程
+
+1. 每当软件包仓库有新的PR提交时，bot首先会检查PR提交者的贡献者协议（CLA协议）签署情况，如果已签署，则会自动进入CI测试流程。
+
+
+
+2. 如果未签署，则会评论PR提示提交者未签署CLA协议。
+
+
+
+3. 当开发者签署CLA协议之后，可以在PR中评论/check-cla重新检查协议签署情况，评论/check-cla不会触发测试流程，如需测试，评论/retest即可进入测试流程。
+
+
+
+4. 当测试完成之后，会把测试结果和详细结果链接一起评论到PR中。
+
+
+
+5. 如果测试失败，开发者可在修改代码之后，评论/retest重新进入代码测试流程，或者当有新的代码提交时，也会自动触发重新测试。
+
+
+
+6. maintainer可以评论/skip-test帮助开发者跳过某些可以忽略测试失败的场景。
+7. 当CI测试通过之后，由maintainer进行评审，评审通过后将进行PR合入。
+
+## Nightly流程
+（待后续实现）
+
+# 可用命令
+| 回复命令 | 功能 | 可使用人员 |
+| --- | --- | --- |
+| /check-cla | 检查PR提交者签署CLA协议情况 | PR提交者，openanolis企业成员 |
+| /retest | 重新进入代码测试流程 | PR提交者，openanolis企业成员 |
+| /skip-test | 跳过代码测试流程 | maintainer |
+
+
+# 标签说明
+每次bot操作均会在PR上打上状态标签，开发者可根据标签信息判断当前流程，并进行后续操作：
+
+| 标签 | 说明 |
+| --- | --- |
+| anolis_cla_pass | PR提交者已签署CLA协议 |
+| anolis_cla_fail | PR提交者未签署CLA协议 |
+| anolis_testing | 代码测试中 |
+| code_update | 代码测试中发生了代码更新 |
+| anolis_test_pass | 代码测试通过 |
+| anolis_test_fail | 代码测试未通过 |
+
+
+# 检测项
+| 测试类型 | 测试项 | 描述 |
+| --- | --- | --- |
+| 合规检查 | check_license
许可证检查 | 对spec文件和源码中的许可证进行检查 |
+| 代码检查 | check_spec_file
Spec检查 | 对spec文件进行格式检查 |
+| 代码检查 | check_code_style
编码规范 | 对源文件做检查，目前支持c/c++,python,shell |
+| 构建测试 | abs_build
ABS构建 | 调用ABS构建服务进行软件包构建，回传rpm包链接 |
+| 冒烟测试 | pkg_smoke_test
RPM Smoke | 下载rpm软件包，安装测试，命令行测试，LDD检查等，依赖构建测试结果 |
+| 兼容性测试 | check_abi_diff
ABI兼容性测试 | 对rpm包的前后版本进行abidiff检查，依赖构建测试结果 |
+| 依赖测试 | check_pkg_dependency
软件包依赖测试 | 对rpm包的前后版本进行依赖包检查，依赖构建测试结果 |
+
+# 接入方式
+在OpenAnolis企业账户下的所有仓库默认接入PackageCI流程，对每个PR进行测试。
同时，如果您有以下需求：
+
+1. OpenAnolis企业里的仓库想在PR中运行其他的CI测试
+2. 其他平台的软件包仓库也想进行PackageCI测试
+3. 想针对某个仓库进行Nightly级别的CI测试
+4. 等等
+
+
+通过在anolis/ci-meta仓库中提交PR进行注册，即可接入PackageCI流程，满足您的个性化测试需求，详细接入规范请参考《CI-META仓库配置规范》。
diff --git a/CESHI_ZHUANYONG/menu.yaml b/CESHI_ZHUANYONG/menu.yaml
index abe17f710c5c528b79bd46423992da88ff90eacc..eeea582306d182549f44014f672ab672ca76b25f 100644
--- a/CESHI_ZHUANYONG/menu.yaml
+++ b/CESHI_ZHUANYONG/menu.yaml
@@ -4,4 +4,32 @@ CESHI_ZHUANYONG:
CI及代码门禁:
CI-META仓库配置规范: ../CI及代码门禁/CI-META仓库配置规范.md
内核代码门禁系统使用指南: ../CI及代码门禁/内核代码门禁系统使用指南.md
- 龙蜥内核CI服务-KernelCI: ../CI及代码门禁/龙蜥内核CI服务-KernelCI.md
\ No newline at end of file
+ 龙蜥内核CI服务-KernelCI: ../CI及代码门禁/龙蜥内核CI服务-KernelCI.md
+ 龙蜥容器CI服务-DockerCI: ../CI及代码门禁/龙蜥容器CI服务-DockerCI.md
+ 龙蜥软件包CI服务-PackageCI: ../CI及代码门禁/龙蜥软件包CI服务-PackageCI.md
+ 安全管理系统:
+ ANAS用户API说明文档: ../安全管理系统/ANAS用户API说明文档.md
+ ANAS鉴权失败自助排查手册: ..安全管理系统/ANAS鉴权失败自助排查手册.md
+ OpenAnolis安全数据API文档: ../安全管理系统/OpenAnolis安全数据API文档.md
+ 龙蜥操作系统漏洞评分定级说明: ../安全管理系统/龙蜥操作系统漏洞评分定级说明.md
+ 构建平台ABS:
+ LifseaOS 镜像: ../构建平台ABS/LifseaOS 镜像.md
+ 云原生: ../构建平台ABS/云原生.md
+ 内核源码: ../构建平台ABS/内核源码.md
+ 软件包构建: ../构建平台ABS/软件包构建.md
+ 镜像: ../构建平台ABS/镜像.md
+ 测试平台T-One:
+ T-One文档: ../测试平台T-One/T-One文档.md
+ 社区管理流程:
+ CLA 签署操作手册: ../社区管理流程/CLA 签署操作手册.md
+ FAQ: ../社区管理流程/FAQ.md
+ SIG 管理: ../社区管理流程/SIG 管理.md
+ 软件制品中心PackageCenter:
+ pkgcenter API文档: ../软件制品中心PackageCenter/pkgcenter API文档.md
+ 镜像制作平台:
+ 用户文档: ../镜像制作平台/用户文档.md
+ 龙蜥 PyPI 仓:
+ 用户文档: ../龙蜥 PyPI 仓/用户文档.md
+ 龙蜥实验室:
+ 龙蜥实验室生态设备专区指南: ../龙蜥实验室/龙蜥实验室生态设备专区指南.md
+ 龙蜥实验室课程接入指导: ../龙蜥实验室/龙蜥实验室课程接入指导.md
\ No newline at end of file