Pull Request已成功合入, 合并人@CANN-robot
（感谢 han zhang 的贡献）
变更摘要
此 PR 为 catlass 仓库新增了基于 gitcode 平台的 CI/CD 流水线配置，包含 ARM 编译、预冒烟测试、代码检查及静态检查等全套自动化工作流。主工作流 catlass_action.yml 通过 PR 评论中的 /compile 命令触发，协调多个子工作流按阶段执行，各作业间通过华为云 OBS 进行制品传递。
主要改动
- 新增主工作流
catlass_action.yml：作为顶层编排入口，定义了 PR 触发条件（/compile评论）、并发控制（最大 5 个、按 mr_id 抢占），并按stage1（镜像选择、PR 文件获取）和stage2（编译、冒烟、各类检查）两个阶段串联执行。 - 新增 ARM 编译工作流
arm_compile_action.yml及脚本arm_compile.sh：在 ARM64 专用节点上通过build-accelerate插件执行tests/test_compile.sh完成 ARM 平台编译，编译产物和编译脚本均通过 OBS 传递。 - 新增 ARM 预冒烟工作流
arm_pre_smoke.yml及脚本pre_smoke.sh：通过manifest-management-plugin在 ARM 自托管节点上部署冒烟环境，执行tests/run_all_test.sh，并在完成后清理资源。 - 新增代码检查工作流
codecheck_action.yml：包含precommit、check-pr、sca、antiposion（反病毒）、codecheck五个并行作业，分别进行提交规范检查、PR 内容校验、软件成分分析、病毒扫描和代码规范扫描。 - 新增静态检查工作流
staticcheck_action.yml：通过cann/.gitcode/actions/staticcheck复用动作支持多种检查类型（markdown、codespell_check、tag_closed_check、resource_existence_check、link_validity_check），检查结果以 CSV/JSON 格式上传至 OBS。
代码审查
审查结果汇总
| 文件 | 审查结论 |
|---|---|
.gitcode/scripts/arm_compile.sh |
发现 2 个问题（P2 × 2） |
.gitcode/scripts/pre_smoke.sh |
发现 2 个问题（P2 × 1, P3 × 1） |
.gitcode/workflows/arm_compile_action.yml |
发现 1 个问题（P2 × 1）；其余无问题 |
.gitcode/workflows/arm_pre_smoke.yml |
发现 2 个问题（P1 × 1, P3 × 1）；其余无问题 |
.gitcode/workflows/catlass_action.yml |
发现 1 个问题（P2 × 1）；其余无问题 |
.gitcode/workflows/codecheck_action.yml |
发现 3 个问题（P1 × 2, P2 × 1）；其余无问题 |
.gitcode/workflows/staticcheck_action.yml |
发现 2 个问题（P2 × 1, P3 × 1）；其余无问题 |
共计 13 个发现：P1 × 2、P2 × 7、P3 × 4。
整体风险评估：中高风险
本次变更为 catlass 仓库新增了完整的 CI/CD pipeline（7 个文件，+595 行）。最严重的问题是：
codecheck_action.yml中两处 obs-download 缺少鉴权凭证（P1）——将导致JOB_precommit和JOB_check_pr必然失败。arm_pre_smoke.yml的 outputs 引用了不存在的 job（P1）——复制粘贴错误，输出永远为空。- 两个 Shell 脚本中
set -e与ret=$?的错误处理模式冲突（P2）——自定义错误消息永远不会被打印。 catlass_action.yml中 env 块变量自引用（P2）——可能因平台差异导致 OBS 路径异常。staticcheck_action.yml中commit_id硬编码为'0'（P2）——可能导致静态检查结果不可靠。
建议在启用门禁前修复所有 P1 和 P2 问题。
| 类型 | 数量 |
|---|---|
| 🔴 阻塞 | 3 |
| 🟡 建议 | 5 |
⛔ 需要修改
Thanks for your pull-request.
The full list of commands accepted by me can be found at here。
You can get sig-info at here
PR Approval Progress
✅ Congratulations! All modules have met the lgtm and approve requirements.
Module Approval Details
| module | lgtm status | approve status |
|---|---|---|
| .gitcode | ✅ 宋常霞, tanghaoran7 (2/2) | ✅ 宋常霞 (1/1) |
💡 Tip:
- Committer can comment
/approveor/lgtm- Commenting
/approveimplies both code review (lgtm) and intent to merge (approve)
CLA Signature Pass
overfitting_zh, thanks for your pull request. All authors of the commits have signed the CLA. 👍
compile
文档检查门禁结果:
🟡 Medium Priority
与 arm_compile.sh 完全相同的问题：pre_smoke.sh 第 2 行 set -e 使得第 8 行 bash -x tests/run_all_test.sh 失败时脚本立即退出，第 9-13 行的 ret=$? 捕获和错误处理逻辑永远不可达。
此外，第 11 行的错误消息 "build catlass_examples fail" 与脚本实际行为不匹配——这是从 arm_compile.sh 原样复制过来的。pre_smoke.sh 执行的是 tests/run_all_test.sh（冒烟测试），不是编译。错误消息应该反映实际失败的步骤。
证据链：新增第 2 行 set -e + 第 8 行 bash -x tests/run_all_test.sh → 失败时 -e 立即终止 → 第 9-13 行错误处理永远不可达 + 第 11 行错误消息内容不匹配。
建议：将错误处理改为 bash -x tests/run_all_test.sh || { echo "run_all_test fail"; exit 1; }，同时修正错误消息以匹配实际执行的测试脚本。
🟡 Medium Priority
arm_compile.sh 第 2 行设置了 set -e，这意味着任何非零退出的命令会导致脚本立即终止。第 10 行 bash -x tests/test_compile.sh 是一个独立的简单命令，不在 if/while/&&/|| 等抑制 -e 的上下文中。
因此当 tests/test_compile.sh 失败（退出码非零）时，set -e 会使脚本在第 10 行立即退出，永远执行不到第 11 行 ret=$? 和第 12-14 行的错误处理逻辑。第 13 行的自定义错误消息 "build catlass_examples fail" 永远不会被打印。
当 tests/test_compile.sh 成功（退出码 0）时，ret=0，跳过 if 块，执行 exit 0。所以第 11-15 行的代码只在成功路径上有意义（纯属冗余），在失败路径上完全是死代码。
同样的问题也存在于 pre_smoke.sh 第 8-13 行。
证据链：新增第 2 行 set -e + 第 10 行 bash -x tests/test_compile.sh → 失败时 -e 立即终止 → 第 11-14 行错误处理永远不可达 → 自定义错误消息不会输出。
建议：将 bash -x tests/test_compile.sh 和后续的 ret=$? + if 块合并为一行：bash -x tests/test_compile.sh || { echo "build catlass_examples fail"; exit 1; }。或者移除 set -e 中对简单命令的退出行为（改用 set -e 仅配合显式错误处理），让 ret=$? 能够被捕获。
🟠 High Priority
在 arm_pre_smoke.yml 的 workflow_call.outputs 中（第 14、16 行），arm_run_url 和 arm_run_key 的值引用了 jobs.JOB_compile.outputs.primary-url 和 jobs.JOB_compile.outputs.primary-key。但此 workflow 中唯一定义的 job 是第 19 行的 JOB_pre_smoke，根本不存在 JOB_compile。
这是从 arm_compile_action.yml（其中 job 确实叫 JOB_compile）复制粘贴过来的错误。调用方 catlass_action.yml 中 JOB_arm_pre_smoke 没有引用这些 outputs，所以当前不会直接导致调用方失败，但 outputs 永远为空，任何依赖这些 outputs 的下游消费者都将收到空值。
证据链：diff 中新增的第 14 行 → JOB_compile 在本文件中不存在 → outputs 永远为空 → 下游消费者拿到空值。
建议：将 JOB_compile 改为 JOB_pre_smoke，与第 19 行定义的 job id 保持一致。同时确认 JOB_pre_smoke（manifest-management-plugin）确实会产出 primary-url 和 primary-key 这两个 outputs。
changed this line on c62fb3c6 view diff detail
🟠 High Priority
codecheck_action.yml 中 JOB_check_pr 的 obs-download 步骤（第 65-73 行）同样缺少 access-key 和 secret-key 参数。这是同一文件中第二个有此问题的 obs-download 步骤（第一个在 JOB_precommit 第 25-31 行）。其他所有 workflow 文件中的每个 OBS 操作都明确提供了凭证。
证据链：新增第 65-73 行 → 缺少 access-key/secret-key → OBS 下载鉴权失败 → check-pr 无法获取 pr_filelist.txt 和 pr_filelist_mod.txt → job 失败。
建议：在 JOB_check_pr 的 obs-download 步骤中补充 access-key: ${{ secrets.AK }} 和 secret-key: ${{ secrets.SK }}。
|
73 | + - |
|
74 | + name: download |
|
75 | + uses: obs-download |
|
76 | + with: |
|
77 | + endpoint: "https://obs.cn-north-4.myhuaweicloud.com" |
|
78 | + bucket: "ascend-cann-open" |
|
79 | + access-key: ${{ secrets.AK }} |
|
80 | + secret-key: ${{ secrets.SK }} |
|
81 | + key: | |
|
82 | + ${{ env.obs_path }}/pr_filelist.txt |
|
83 | + ${{ env.obs_path }}/pr_filelist_mod.txt |
| 73
84 | path: ${{ steps.process_checkout.outputs.path }} |
🟠 High Priority
codecheck_action.yml 中 JOB_precommit 的 obs-download 步骤（第 25-31 行）和 JOB_check_pr 的 obs-download 步骤（第 65-73 行）缺少 access-key 和 secret-key 参数。
与此形成对比：同一文件中的 obs-upload 步骤（第 41-49 行）以及所有其他 workflow 文件（arm_compile_action.yml 第 35-36 行、arm_pre_smoke.yml 第 43-44 行、staticcheck_action.yml 第 30-31 行、catlass_action.yml 第 76-77 行）中的每个 obs-download / obs-upload 步骤都明确提供了 access-key 和 secret-key。
缺少凭证会导致从 OBS 下载文件时鉴权失败，JOB_precommit 和 JOB_check_pr 两个 job 将无法获取所需的 pr_filelist_precommit.txt / pr_filelist.txt / pr_filelist_mod.txt 文件。
证据链：新增第 25-31 行和 65-73 行 → 缺少 access-key/secret-key → 与其他所有 OBS 步骤不一致 → OBS 下载鉴权失败 → job 失败。
建议：在 JOB_precommit 和 JOB_check_pr 的 obs-download 步骤中补充 access-key: ${{ secrets.AK }} 和 secret-key: ${{ secrets.SK }}。如果 OBS bucket 是公开读取的可以不需要凭证，但为了与其他步骤保持一致并防止 bucket 策略变更，建议统一加上。
|
31 | + - |
|
32 | + name: download |
|
33 | + uses: obs-download |
|
34 | + with: |
|
35 | + endpoint: "https://obs.cn-north-4.myhuaweicloud.com" |
|
36 | + bucket: "ascend-cann-open" |
|
37 | + access-key: ${{ secrets.AK }} |
|
38 | + secret-key: ${{ secrets.SK }} |
|
39 | + key: "${{ env.obs_path }}/pr_filelist_precommit.txt" |
| 31
40 | path: ${{ steps.process_checkout.outputs.path }} |
🟡 Medium Priority
arm_compile_action.yml 第 52 行：
引用的是 env.target_branch（全小写）。但调用方 catlass_action.yml 第 24 行定义的 env 变量名为 TARGET_BRANCH（全大写）：
两者大小写不一致。环境变量名区分大小写，env.target_branch 与 env.TARGET_BRANCH 是不同的变量。因此 export target_branch=... 会被设置为空字符串。虽然后续 arm_compile.sh 脚本中并未直接使用 target_branch 变量，但如果将来脚本中需要用到或 build-accelerate 框架依赖此变量，将获取不到正确的目标分支。
证据链：新增第 52 行 → env.target_branch（小写）→ 对应 catlass_action.yml 第 24 行 TARGET_BRANCH（大写）→ 大小写不匹配 → 变量为空。
建议：将 env.target_branch 改为 env.TARGET_BRANCH，与 catlass_action.yml 中的定义保持一致。
| 52
| - export target_branch=${{ env. |
|
52 | + export target_branch=${{ env.TARGET_BRANCH }} |
changed this line on c62fb3c6 view diff detail
🟡 Medium Priority
arm_compile.sh 第 4 行 cd ${WORKSPACE} 存在两个问题：
-
变量未加引号：
${WORKSPACE}未用双引号包裹。如果WORKSPACE的值包含空格或特殊字符，会导致路径解析错误或潜在的 glob 展开。 -
空值不报错：当
WORKSPACE未设置或为空时，cd不带参数执行（等同于cd），会静默跳转到$HOME目录。由于set -e在cd成功时不会触发退出，后续所有pip3 install、source、bash tests/test_compile.sh都将在错误的目录（$HOME）下执行——要么找不到文件而失败，要么在错误位置运行。
WORKSPACE 由外部 arm_compile_action.yml 第 49 行通过 export WORKSPACE=${{ steps.process_checkout.outputs.path }} 设置，正常情况下不会为空。但如果 build-accelerate 传递环境变量失败或 checkout 步骤异常，此防护缺失将成为隐患。
证据链：新增第 4 行 → cd ${WORKSPACE} 未加引号且无空值检测 → WORKSPACE 为空时静默跳转 HOME → 后续命令在错误目录执行。
建议：将 cd ${WORKSPACE} 改为 cd "${WORKSPACE}"。如果业务上要求 WORKSPACE 不能为空，可以在此之前加上 : "${WORKSPACE:?WORKSPACE is not set}" 进行防御性检查。
| 4
| - cd ${WORKSPACE} |
|
4 | + cd "${WORKSPACE}" |
changed this line on c62fb3c6 view diff detail
🟡 Medium Priority
staticcheck_action.yml 第 46 行将 commit_id 硬编码为字符串 '0'：
commit_id: '0'
而该 workflow 在第 22 行已经 checkout 了正确的 commit（${{ atomgit.event.pull_request.merge_commit_sha || atomgit.sha }}），表明实际 commit SHA 是可获取的。commit_id: '0' 看起来是一个未完成的占位符。cann/.gitcode/actions/staticcheck@master 这个 action 如果使用 commit_id 做基线对比或追踪，传 '0' 会导致检查结果不可靠（例如无法正确确定变更范围，或将所有文件标记为新增）。
证据链：新增第 46 行 → commit_id: '0' 硬编码 → 未使用实际的 merge_commit_sha → staticcheck action 可能产生错误的检查结果。
建议：将 commit_id: '0' 替换为实际的 commit SHA：${{ atomgit.event.pull_request.merge_commit_sha || atomgit.sha }}，与同文件中 checkout 步骤（第 22 行）使用的 ref 保持一致。如果 '0' 在该 action 中确实有特殊语义（如表示"不使用基线"），请添加注释说明。
han zhang| 阶段 | 任务名 | 状态 | 详情 |
|---|---|---|---|
| 编译构建 | Build_arm | ✅ | >>> |
| 恶意代码检查 | Antipoison | ✅ | >>> |
| 编码安全与规范检查 | CodeCheck_pre-commit | ✅ | >>> |
| 开源片段检查 | SCA | ✅ | >>> |
| pre-commit | pre-commit | ✅ | >>> |
| static_check_markdownlint | ✅ | >>> | |
| static_check_link_validity | ✅ | >>> | |
| static_check_resource_check | ✅ | >>> | |
| static_check_codespell_check | ✅ | >>> | |
| static_check_tag_closed_check | ✅ | >>> | |
| 开发者测试 | UT_arm | 🟨 | >>> |
| 流水线 | PR-pipeline_catlass | 🟨 | >>> |
- compile : 运行流水线
- retry : 重试流水线所有失败子任务
- retry <任务名> : 仅重试指定失败子任务
- stop : 停止流水线
compile
| 阶段 | 任务名 | 状态 | 详情 |
|---|---|---|---|
| 编译构建 | Build_arm | ✅ | >>> |
| 恶意代码检查 | Antipoison | ✅ | >>> |
| 编码安全与规范检查 | CodeCheck_pre-commit | ✅ | >>> |
| 开源片段检查 | SCA | ✅ | >>> |
| pre-commit | pre-commit | ✅ | >>> |
| static_check_markdownlint | ✅ | >>> | |
| static_check_link_validity | ✅ | >>> | |
| static_check_resource_check | ✅ | >>> | |
| static_check_codespell_check | ✅ | >>> | |
| static_check_tag_closed_check | ✅ | >>> | |
| 开发者测试 | UT_arm | ✅ | >>> |
| 流水线 | PR-pipeline_catlass | ✅ | >>> |
- compile : 运行流水线
- retry : 重试流水线所有失败子任务
- retry <任务名> : 仅重试指定失败子任务
- stop : 停止流水线
/lgtm
/approve
Pull Request 已合并或已关闭。
If you want to solve this problem, you can click here to do it in the FAQs.
Pull Request 已合并或已关闭。
If you want to solve this problem, you can click here to do it in the FAQs.
描述
catlass仓上gitcode action
关联的Issue
原因
catlass仓上gitcode action，暂时不影响门禁待陪跑完成后切换。
测试
文档更新
类型标签