feat(ci): 接入 AgentLoop Trace 上报，实现 CI 全链路监控 #598

2026-07-19T17:13:14+08:00

xiaoxia commented

2026-07-19 17:13:14 +08:00

变更说明

为 9 个 CI workflow 接入 AgentLoop Trace 上报，实现 CI 全链路统一监控。

改动内容

新增文件

.gitea/scripts/ci_trace_report.py - 通用 Trace 上报脚本（使用标准库 urllib，无外部依赖）

修改文件（9 个 workflow，共 24 个 job）

ci-build.yml (7 jobs) - CI构建
ci-cd.yml (6 jobs) - CI/CD流水线
code-review.yml (1 job) - AI代码审查
auto-approve.yml (1 job) - 自动批准
auto-merge.yml (1 job) - 自动合并
preview-deploy.yml (1 job) - 预览环境部署
preview-cleanup.yml (1 job) - 预览环境清理
ci-trigger-monitor.yml (1 job) - CI触发监控
daily-check.yml (5 jobs) - 每日健康检查

实现方式

每个 job 添加 2 个步骤：

开始时：上报 running 状态的 Trace，记录开始时间
结束时：上报最终状态（ok/error），计算总耗时（if: always() 确保失败也上报）

安全特性

🔒 AgentLoop 密钥通过 Gitea Secrets 注入，不硬编码
🛡️ 上报失败静默处理（exit 0），不影响 CI 主流程
📦 使用 Python 标准库 urllib，无额外依赖安装

前置依赖

需要在 Gitea Actions Secrets 中配置以下变量：

AGENTLOOP_ENDPOINT - Trace 上报地址（可选，有默认值）
AGENTLOOP_LICENSE_KEY - LicenseKey（必填）
AGENTLOOP_PROJECT - SLS Project 名（可选）
AGENTLOOP_WORKSPACE - CMS Workspace 名（可选）

## 变更说明为 9 个 CI workflow 接入 AgentLoop Trace 上报，实现 CI 全链路统一监控。 ## 改动内容 ### 新增文件 - `.gitea/scripts/ci_trace_report.py` - 通用 Trace 上报脚本（使用标准库 urllib，无外部依赖） ### 修改文件（9 个 workflow，共 24 个 job） - `ci-build.yml` (7 jobs) - CI构建 - `ci-cd.yml` (6 jobs) - CI/CD流水线 - `code-review.yml` (1 job) - AI代码审查 - `auto-approve.yml` (1 job) - 自动批准 - `auto-merge.yml` (1 job) - 自动合并 - `preview-deploy.yml` (1 job) - 预览环境部署 - `preview-cleanup.yml` (1 job) - 预览环境清理 - `ci-trigger-monitor.yml` (1 job) - CI触发监控 - `daily-check.yml` (5 jobs) - 每日健康检查 ## 实现方式每个 job 添加 2 个步骤： 1. **开始时**：上报 running 状态的 Trace，记录开始时间 2. **结束时**：上报最终状态（ok/error），计算总耗时（`if: always()` 确保失败也上报） ## 安全特性 - 🔒 AgentLoop 密钥通过 Gitea Secrets 注入，不硬编码 - 🛡️ 上报失败静默处理（exit 0），不影响 CI 主流程 - 📦 使用 Python 标准库 urllib，无额外依赖安装 ## 前置依赖需要在 Gitea Actions Secrets 中配置以下变量： - `AGENTLOOP_ENDPOINT` - Trace 上报地址（可选，有默认值） - `AGENTLOOP_LICENSE_KEY` - LicenseKey（必填） - `AGENTLOOP_PROJECT` - SLS Project 名（可选） - `AGENTLOOP_WORKSPACE` - CMS Workspace 名（可选）

xiaoxia force-pushed feature/agentloop-ci-trace from 295d53b17d to 833c08a10d

2026-07-19 18:04:07 +08:00

Compare

auto-approve-bot commented

2026-07-19 18:05:41 +08:00

📊 审查概览

整体评价：需修改
严重问题数量：1 个
一般建议数量：2 个

❌ 需修改的问题（严重）

[.gitea/workflows/ci-build.yml: 多处] Trace 上报功能未生效
- 问题描述：在 ci-build.yml 的大部分 job（如 build-staging, deploy-staging 等）中，新增的步骤里设置了 TRACE_SERVICE=""。根据 ci_trace_report.py 的逻辑（第 316 行），如果 service_name 为空，脚本会打印警告并直接 sys.exit(0)，导致实际上并没有上报任何 Trace 数据。只有 acr-cleanup job 配置了有效的 TRACE_SERVICE="ci-build"。
- 修改建议：请检查所有新增的 Trace 上报步骤，为 TRACE_SERVICE 赋予正确的服务名称（例如 ci-build, deploy-staging 等），或者删除该环境变量赋值（如果脚本支持从环境变量自动推断，但当前脚本逻辑不支持，必须显式指定）。

💡 改进建议（一般）

[.gitea/scripts/ci_trace_report.py: 22-24] 硬编码基础设施配置
- 具体内容：脚本中硬编码了 DEFAULT_ENDPOINT、DEFAULT_PROJECT 和 DEFAULT_WORKSPACE，其中包含了阿里云的 Region（cn-hangzhou）和内部 ID。这降低了代码的通用性，如果需要在其他区域或环境运行，或者这些 ID 发生变更，需要修改代码。建议这些配置应完全通过环境变量注入，或者在未设置环境变量时明确报错，而不是静默使用硬编码的默认值。
[.gitea/scripts/ci_trace_report.py: 136] 异常处理过于宽泛
- 具体内容：在 _get_pr_number 函数中，使用了 except Exception: pass 来捕获所有异常。虽然这是为了防止 Trace 上报失败影响 CI 流程，但这样会掩盖潜在的问题（如 JSON 解析错误、文件权限问题等），导致排查困难。建议至少将异常信息打印到 stderr，以便调试。

✅ 良好实践

手动 Protobuf 编码：在不引入第三方依赖（如 protobuf 库）的情况下，手动实现 OTLP 的部分编码，逻辑清晰且减少了 CI 环境的依赖复杂度。
容错设计：Python 脚本主逻辑和 Shell 脚本中均使用了 set +e 和 exit 0，确保 Trace 上报的失败不会阻断主要的 CI 流程，符合可观测性组件的设计原则。
兼容性处理：_env 函数同时支持 GITEA_ 和 GITHUB_ 前缀，增强了脚本在不同 CI 平台间的兼容性。

✅ 格式检查通过 | ❌ 逻辑审查需修改 | ✅ 性能良好

_{🤖 由 AI 代码审查机器人自动生成 | 2026-07-19 18:05:41 | 模型:}

### 📊 审查概览 - **整体评价**：需修改 - **严重问题数量**：1 个 - **一般建议数量**：2 个 ### ❌ 需修改的问题（严重） 1. **[.gitea/workflows/ci-build.yml: 多处] Trace 上报功能未生效** - **问题描述**：在 `ci-build.yml` 的大部分 job（如 `build-staging`, `deploy-staging` 等）中，新增的步骤里设置了 `TRACE_SERVICE=""`。根据 `ci_trace_report.py` 的逻辑（第 316 行），如果 `service_name` 为空，脚本会打印警告并直接 `sys.exit(0)`，导致实际上并没有上报任何 Trace 数据。只有 `acr-cleanup` job 配置了有效的 `TRACE_SERVICE="ci-build"`。 - **修改建议**：请检查所有新增的 Trace 上报步骤，为 `TRACE_SERVICE` 赋予正确的服务名称（例如 `ci-build`, `deploy-staging` 等），或者删除该环境变量赋值（如果脚本支持从环境变量自动推断，但当前脚本逻辑不支持，必须显式指定）。 ### 💡 改进建议（一般） 1. **[.gitea/scripts/ci_trace_report.py: 22-24] 硬编码基础设施配置** - **具体内容**：脚本中硬编码了 `DEFAULT_ENDPOINT`、`DEFAULT_PROJECT` 和 `DEFAULT_WORKSPACE`，其中包含了阿里云的 Region（`cn-hangzhou`）和内部 ID。这降低了代码的通用性，如果需要在其他区域或环境运行，或者这些 ID 发生变更，需要修改代码。建议这些配置应完全通过环境变量注入，或者在未设置环境变量时明确报错，而不是静默使用硬编码的默认值。 2. **[.gitea/scripts/ci_trace_report.py: 136] 异常处理过于宽泛** - **具体内容**：在 `_get_pr_number` 函数中，使用了 `except Exception: pass` 来捕获所有异常。虽然这是为了防止 Trace 上报失败影响 CI 流程，但这样会掩盖潜在的问题（如 JSON 解析错误、文件权限问题等），导致排查困难。建议至少将异常信息打印到 stderr，以便调试。 ### ✅ 良好实践 - **手动 Protobuf 编码**：在不引入第三方依赖（如 `protobuf` 库）的情况下，手动实现 OTLP 的部分编码，逻辑清晰且减少了 CI 环境的依赖复杂度。 - **容错设计**：Python 脚本主逻辑和 Shell 脚本中均使用了 `set +e` 和 `exit 0`，确保 Trace 上报的失败不会阻断主要的 CI 流程，符合可观测性组件的设计原则。 - **兼容性处理**：`_env` 函数同时支持 `GITEA_` 和 `GITHUB_` 前缀，增强了脚本在不同 CI 平台间的兼容性。 --- ✅ 格式检查通过 | ❌ 逻辑审查需修改 | ✅ 性能良好 --- <sub>🤖 由 AI 代码审查机器人自动生成 | 2026-07-19 18:05:41 | 模型: </sub>

xiaoxia added 1 commit 2026-07-19 18:09:23 +08:00

feat(ci): 接入 AgentLoop Trace 上报 (rebase onto develop) 442413581d

为所有 CI workflow 的所有 job 添加 Trace 上报步骤，
包含从 develop 合入的 ACR 镜像清理策略等最新改动。

xiaoxia force-pushed feature/agentloop-ci-trace from 833c08a10d to 442413581d

2026-07-19 18:09:23 +08:00

Compare

xiaoxia referenced this pull request

2026-07-20 09:13:20 +08:00

feat(ci): 接入AgentLoop Trace上报，实现CI全链路监控 (#598) #624