Github MCP Server Devops

ActionsPulse是一个MCP服务器，通过GitHub Copilot在IDE中提供GitHub Actions的实时可观测性，包括DORA指标、成本分析、CI/CD健康状况和安全合规报告，并生成交互式仪表板。

开发者工具监控 #DevOps监控 #CI/CD分析 #成本优化 #安全合规 .TypeScript

评分 : 2.5分

下载量 : 4.1K

更新时间 : 2026-03-12

打开站点

什么是ActionsPulse?

ActionsPulse是一个Agentic MCP服务器，它将DevOps观测能力直接集成到你的IDE中。你可以通过GitHub Copilot询问关于你的GitHub Actions性能、成本、安全性和合规性的问题，并获得交互式可视化仪表板。

如何使用ActionsPulse?

安装ActionsPulse MCP服务器后，你可以在VS Code或Cursor中直接与GitHub Copilot对话，询问DevOps相关问题。系统会自动调用相应的工具获取数据并生成可视化报告。

适用场景

适用于需要监控GitHub Actions性能、优化CI/CD成本、评估团队DevOps成熟度、生成合规性报告以及跟踪DORA指标的开发团队、DevOps工程师和工程经理。

主要功能

DORA指标分析

跟踪部署频率、变更前置时间、变更失败率和平均恢复时间等关键DevOps性能指标，并与行业标准进行对比。

性能分析

深入分析CI/CD管道健康状况，包括工作流成功率、平均运行时间、P95/P99延迟和失败模式分析。

成本优化

分析GitHub Actions运行器成本，按仓库、工作流和操作系统进行细分，并提供可操作的节约建议。

运行器利用率

监控自托管和GitHub托管运行器的使用效率，识别闲置资源和优化机会。

团队生产力

基于Actions和提交数据评估团队开发效率，包括PR合并率、问题解决时间等指标。

合规性报告

生成符合SOC2、ISO27001、HIPAA、PCI-DSS等标准的审计就绪报告，包括安全扫描状态和分支保护规则。

缓存分析

分析GitHub Actions缓存使用效率，识别缓存命中率和优化机会。

成熟度评估

评估组织的DevOps成熟度水平，提供改进建议和行业基准对比。

优势

直接在IDE中获取DevOps洞察，无需切换工具

交互式HTML仪表板，支持团队共享和嵌入

支持自然语言查询，降低使用门槛

提供可操作的建议，不仅仅是数据展示

支持企业级功能，包括跨组织分析和合规性报告

灵活的仓库过滤机制，支持动态和静态配置

局限性

需要GitHub Copilot订阅才能获得最佳体验

某些高级功能需要GitHub Advanced Security许可证

企业级功能需要GitHub Enterprise订阅

需要配置GitHub个人访问令牌，涉及权限管理

对于非常大的组织，API调用可能受到速率限制

如何使用

创建GitHub个人访问令牌

在GitHub设置中创建细粒度个人访问令牌，授予必要的仓库和权限。建议设置90天有效期，并选择访问所有仓库。

配置MCP服务器

在VS Code或Cursor的MCP配置文件中添加ActionsPulse服务器配置。可以使用Docker运行或直接通过npm启动。

设置环境变量

配置必要的环境变量，包括GitHub令牌、组织名称和可选的仓库过滤器。建议使用环境文件以提高安全性。

重启IDE并开始使用

重启VS Code或Cursor以加载MCP服务器配置。打开GitHub Copilot聊天界面，开始询问DevOps相关问题。

使用案例

监控团队DevOps性能

工程经理需要了解团队的DevOps性能指标，包括部署频率、变更失败率和平均恢复时间。

优化CI/CD成本

DevOps工程师需要识别GitHub Actions的成本驱动因素，并找到节约机会。

准备合规性审计

安全团队需要为SOC2审计准备合规性报告，证明CI/CD管道符合安全标准。

评估DevOps成熟度

技术总监希望评估组织的DevOps成熟度水平，并制定改进路线图。

常见问题

我需要GitHub Copilot才能使用ActionsPulse吗？

ActionsPulse支持哪些GitHub版本？

如何控制ActionsPulse访问哪些仓库？

ActionsPulse会存储我的GitHub数据吗？

如何自动化生成DevOps报告？

什么是仓库层级（tier）？如何定义？

🚀 ActionsPulse

ActionsPulse 是一款能够通过 VS Code 和 GitHub Copilot 实现对 GitHub Actions 进行实时观测的工具。它可以提供 DORA 指标、成本分析、CI/CD 健康状况以及安全合规性等方面的信息，帮助用户更好地管理 DevOps 流程。

🚀 快速开始

从 MCP 注册表安装

ActionsPulse 已发布到官方 MCP 注册表，名称为 io.github.tsviz/actions-pulse。

🌐 网页用户界面（推荐）：使用 MCP 注册表用户界面一键安装到 VS Code 或 Cursor：

访问 vemonet.github.io/mcp-registry。
搜索 "actions-pulse"。
点击安装 → 选择你的客户端（VS Code 或 Cursor）。
当提示时配置环境变量。

手动 Docker 设置：或者按照以下步骤手动配置。

前提条件

✅ 已安装 Docker
✅ 拥有 GitHub 个人访问令牌（推荐使用细粒度令牌）
✅ 安装了 GitHub Copilot 的 VS Code

1. 创建细粒度个人访问令牌

访问 GitHub 设置 → 开发者设置 → 个人访问令牌 → 细粒度令牌。
点击 生成新令牌。
配置基本设置：
- 令牌名称：actions-pulse-mcp
- 过期时间：90 天（或根据你的安全策略设置）
- 资源所有者：选择你的组织
- 仓库访问权限：所有仓库
设置 仓库权限： | 权限 | 访问级别 | 是否必需 | 用途 | | ---- | ---- | ---- | ---- | | Actions | 读取 | ✅ 是 | 工作流运行、缓存使用情况 | | 管理 | 读取 | ✅ 是 | 计费数据、仓库设置 | | 内容 | 读取 | ✅ 是 | 从 devops-config 仓库读取配置文件 | | 自定义属性 | 读取 | ✅ 是 | 读取仓库上的自定义属性值 | | 部署 | 读取 | ✅ 是 | 部署频率、环境（DORA 指标） | | 讨论 | 读取 | 🔶 可选 | 社区参与度指标 | | 环境 | 读取 | ✅ 是 | 环境保护规则 | | 问题 | 读取 | ✅ 是 | 问题指标、解决时间（DORA 指标） | | 合并队列 | 读取 | 🔶 可选 | 合并队列采用情况和等待时间 | | 元数据 | 读取 | ✅ 是 | 基本仓库信息（自动授予） | | 拉取请求 | 读取 | ✅ 是 | PR 指标、前置时间、审查时间（DORA 指标） |
设置 组织权限： | 权限 | 访问级别 | 是否必需 | 用途 | | ---- | ---- | ---- | ---- | | 自定义属性 | 读取 | ✅ 是 | 读取组织级别的属性定义/模式 | | 组织自定义属性 | 读取 | ✅ 是 | 读取分配给仓库的属性值 |
继续设置 组织权限： | 权限 | 访问级别 | 是否必需 | 用途 | | ---- | ---- | ---- | ---- | | 成员 | 读取 | 🔶 可选 | 团队成员信息，用于生产力指标 | | 自托管运行器 | 读取 | 🔶 可选 | 运行器利用率指标 | | 管理 | 读取 | ✅ 是 | 组织计费和设置 |
可选权限（用于合规性功能，需要 GitHub Advanced Security）： | 权限 | 访问级别 | 是否必需 | 用途 | | ---- | ---- | ---- | ---- | | 密钥扫描警报 | 读取 | ❌ 可选 | 合规性审计报告 | | 代码扫描警报 | 读取 | ❌ 可选 | 合规性审计报告 |
点击 生成令牌 并安全保存。

2. 配置 MCP 服务器

选项 A：使用环境文件（推荐）

在 ~/.mcp.env 中添加以下内容：

GITHUB_TOKEN=ghp_your_fine_grained_token_here

📄 使用环境文件的 mcp.json

在 VS Code 的 MCP 设置（`~/.vscode/mcp.json` 或工作区 `.vscode/mcp.json`）中添加以下内容： ```jsonc { "servers": { "actions-pulse": { "command": "docker", "args": [ "run", "-i", "--rm", "--env-file", "/path/to/.mcp.env", "-e", "GITHUB_ORG=your-org-name", "ghcr.io/tsviz/actions-pulse:latest" ], "type": "stdio" } } } ```

选项 B：直接使用环境变量

📄 使用内联环境变量的 mcp.json

```jsonc { "servers": { "actions-pulse": { "command": "docker", "args": [ "run", "-i", "--rm", "-e", "GITHUB_TOKEN=ghp_your_token", "-e", "GITHUB_ORG=your-org-name", "ghcr.io/tsviz/actions-pulse:latest" ], "type": "stdio" } } } ```

3. 环境变量参考

变量	是否必需	描述
`GITHUB_TOKEN`	✅ 是	个人访问令牌（推荐使用细粒度令牌）
`GITHUB_ORG`	✅ 是	要监控的目标 GitHub 组织（例如 `my-company`）。所有 API 调用都使用此组织。
`DEFAULT_REPO_FILTER`	❌ 否	要监控的仓库的逗号分隔列表（例如 `my-app,my-api`）。请参阅下面的仓库过滤优先级规则。
`GITHUB_API_URL`	❌ 否	自定义 API URL（默认：`https://api.github.com`）
`GITHUB_ENTERPRISE_SLUG`	❌ 否	企业 slug，用于增强功能
`GITHUB_ENTERPRISE_URL`	❌ 否	GitHub Enterprise Server API URL
`DEVOPS_CONFIG_REPO`	❌ 否	配置仓库名称（默认：`devops-config`）
`DEVOPS_CONFIG_PATH`	❌ 否	配置文件的本地路径（用于挂载配置）

仓库过滤优先级

在确定要查询的仓库时，ActionsPulse 使用以下优先级（从高到低）：

优先级	来源	适用范围	示例
1️⃣	工具调用中的 `repo_filter` 参数	单个工具	`get_dora_metrics(repo_filter: "app1,app2")`
2️⃣	`inventory.yaml` 中的仓库	`generate_devops_reports`	配置文件中定义的仓库
3️⃣	`DEFAULT_REPO_FILTER` 环境变量	所有工具（备用）	`DEFAULT_REPO_FILTER=my-app,my-api`
4️⃣	通过 GitHub API 获取的所有组织仓库	所有工具	（如果未设置任何内容，则为默认值）

提示：如果不想使用配置仓库进行快速设置，只需在 MCP 注册表安装程序中设置 DEFAULT_REPO_FILTER。如果需要更丰富的元数据（团队、层级、合规性标签），请使用 inventory.yaml。

4. 配置文件（可选）

默认情况下，ActionsPulse 通过 GitHub API 查询组织中的所有仓库 — 不需要配置文件。你可以使用工具参数（如 repo_filter）动态过滤仓库。

可选的配置文件允许你定义持久的元数据（团队、层级、合规性标签），用于过滤和报告。有两种方法：

选项 A：远程配置仓库（推荐用于团队）

在你的组织中创建一个 devops-config 仓库，结构如下：

devops-config/
├── devops-config.yaml          # 主配置文件
├── repositories/
│   └── inventory.yaml          # 要监控的仓库列表
├── policies/
│   ├── workflow-policies.yaml  # CI/CD 标准
│   └── security-policies.yaml  # 安全要求
└── dashboards/                 # 仪表盘配置

MCP 服务器将自动从 {org}/devops-config 仓库中发现并加载配置。

选项 B：本地配置文件（用于开发/测试）

将本地配置目录挂载到 Docker 容器中：

📄 使用配置卷的 mcp.json

```jsonc { "servers": { "actions-pulse": { "command": "docker", "args": [ "run", "-i", "--rm", "--env-file", "/path/to/.mcp.env", "-e", "GITHUB_ORG=your-org-name", "-e", "DEVOPS_CONFIG_PATH=/app/config", "-v", "/path/to/your/config:/app/config:ro", "ghcr.io/tsviz/actions-pulse:latest" ], "type": "stdio" } } } ```

仓库清单示例

📄 inventory.yaml

创建 `repositories/inventory.yaml` 来定义要监控的仓库： ```yaml apiVersion: actions-pulse/v1 kind: RepositoryInventory metadata: name: my-inventory version: "1.0.0" description: "要监控的仓库"

spec: discovery: enabled: false # 仅监控显式指定的仓库

repositories: - name: my-app team: platform tier: tier-1 compliance: [SOC2] tags: [java, production]

- name: my-api
  team: backend
  tier: tier-2
  tags: [nodejs, staging]

</details>

##### 仓库层级快速参考
| 层级 | 优先级 | 正常运行时间 | 响应时间 | 使用场景 |
| ---- | ---- | ---- | ---- | ---- |
| **tier-1** | 🔴 关键 | 99.9% | < 15 分钟 | 生产环境、面向客户的服务 |
| **tier-2** | 🟡 标准 | 99% | < 1 小时 | 内部工具、预发布环境 |
| **tier-3** | 🟢 低 | 尽力而为 | < 24 小时 | 演示、原型 |

有关完整的层级定义、合规性要求和警报行为，请参阅 [docs/ARCHITECTURE.md](docs/ARCHITECTURE.md)。

#### 5. 重启 VS Code
更新 `mcp.json` 后，重启 VS Code 以加载新的 MCP 服务器。你可以通过打开 GitHub Copilot 聊天并询问 DevOps 指标来验证服务器是否正在运行。

### ✨ 主要特性
| 特性 | 组织版 | 企业版 |
| ---- | ---- | ---- |
| 📊 **DORA 指标** | ✅ | ✅ 增强版 |
| ⚡ **性能分析** | ✅ | ✅ |
| 💰 **成本优化** | ✅ | ✅ 跨组织 |
| 🏃 **运行器利用率** | ✅ 自托管 | ✅ 所有运行器 |
| 👥 **团队生产力** | ✅ | ✅ |
| 🔒 **合规性报告** | ✅ (GHAS) | ✅ |
| 💾 **缓存分析** | ✅ | ✅ |
| 🎓 **成熟度评估** | ✅ | ✅ |

### 💻 使用示例
#### 仪表盘游览
ActionsPulse 生成 **交互式 HTML 仪表盘**，你可以在任何浏览器中打开。只需向 Copilot 提问：
> 💬 *"为我的组织生成 DevOps 报告"*
或者直接使用 `generate_devops_reports` 工具。以下是你将获得的完整游览：
<details open>
<summary><strong>📊 仪表盘概述</strong> — 执行摘要，一眼查看所有关键指标</summary>
主仪表盘提供：
- 🎯 带有可视化仪表盘的 DevOps 成熟度得分
- 📈 DORA 指标摘要（部署频率、前置时间、变更失败率、平均恢复时间）
- ⚡ CI/CD 管道健康状况概述
- 💰 成本分析亮点
- 🔒 安全与合规性状态
- 快速导航到详细报告
</details>
<details>
<summary><strong>📈 DORA 指标</strong> — 行业标准的 DevOps 性能指标</summary>
跟踪四个关键 DORA 指标：
- **部署频率** — 你向生产环境发布的频率
- **变更前置时间** — 从提交到生产的时间
- **变更失败率** — 导致失败的部署百分比
- **平均恢复时间** — 从事故中恢复的速度
每个指标都包括趋势分析和与行业标准（精英、高、中、低绩效者）的基准对比。
</details>
<details>
<summary><strong>⚡ CI/CD 管道健康状况</strong> — 工作流性能和可靠性</summary>
深入了解你的 CI/CD 管道：
- 🔄 工作流成功率和趋势
- ⏱️ 平均运行时间，包括 P95/P99 延迟
- 🚨 失败分析和常见错误模式
- 📊 按仓库和工作流细分
- 🏃 队列时间和运行器利用率
</details>
<details>
<summary><strong>💰 成本优化</strong> — 运行器成本和节省机会</summary>
了解并优化你的 GitHub Actions 支出：
- 💵 按运行器类型（GitHub 托管 vs 自托管）的总成本
- 📊 按仓库、工作流和操作系统的成本细分
- 🎯 可操作的成本节省建议
- 📈 支出趋势和预测
- ⚡ 效率指标（每个工作流的成本、每分钟的成本）
</details>
<details>
<summary><strong>🔒 安全与合规性</strong> — 可用于审计的合规性报告</summary>
保持合规和安全：
- ✅ 合规框架覆盖范围（SOC2、ISO27001、HIPAA、PCI-DSS）
- 🔍 密钥扫描状态和警报
- 🛡️ 代码扫描结果
- 📋 分支保护规则合规性
- 🔐 GHAS（GitHub Advanced Security）功能采用情况
</details>
<details>
<summary><strong>🎓 DevOps 成熟度</strong> — 组织能力评估</summary>
评估你的 DevOps 成熟度级别：
- 📊 带有可视化仪表盘的总体成熟度得分
- 🎯 类别得分（CI/CD、测试、安全、监控等）
- 📈 按影响优先级排序的改进建议
- 🏆 与行业标准的基准对比
- 📋 可操作的改进路线图
</details>

> 💡 **如何生成这些仪表盘**：
> ```
> # 用自然语言询问 Copilot：
> "生成过去 30 天的 DevOps 报告"
> 
> # 或者直接调用工具：
> #generate_devops_reports --timeframe 30d
> ```
> 报告将保存到带时间戳的文件夹中，作为独立的 HTML 文件 — 你可以与团队共享或嵌入到内部维基中！

### 🛠️ 可用工具
<details>
<summary>📊 使用情况和性能指标</summary>
#### get_actions_usage_metrics
分析 GitHub Actions 使用情况和计费数据（基本）。

参数:

org_name: 组织名称（如果设置了 GITHUB_ORG，则可选）
timeframe: '24h' | '7d' | '30d'
breakdown: 'repository' | 'workflow' | 'runner_type'

#### get_detailed_usage_metrics ⭐
**类似 GitHub Insights 的** 详细使用指标，按工作流、作业、仓库、操作系统和运行器细分。

参数:

org_name: 组织名称（如果设置了 GITHUB_ORG，则可选）
timeframe: '7d' | '30d' | '90d'
repo_filter: 逗号分隔的仓库列表（可选）

#### get_detailed_performance_metrics ⭐
**类似 GitHub Insights 的** 性能指标，包括每个工作流/作业/仓库/操作系统/运行器的平均运行时间、队列时间和失败率。

参数:

org_name: 组织名称（如果设置了 GITHUB_ORG，则可选）
timeframe: '7d' | '30d' | '90d'
repo_filter: 逗号分隔的仓库列表（可选）

#### get_actions_performance_metrics
获取带有 P95/P99 延迟的工作流性能分析（基本）。

参数:

org_name: 组织名称（如果设置了 GITHUB_ORG，则可选）
repo_name: 特定仓库（可选）
workflow_id: 特定工作流（可选）
timeframe: '1h' | '6h' | '24h' | '7d'

</details>
<details>
<summary>🏃 运行器和成本优化</summary>
> **增强的成本检测**：报告现在使用三层系统进行准确的运行器成本计算：
> - 🎯 **API 检测** - 使用托管运行器 API 获取精确的机器规格
> - 🏷️ **标签检测** - 与运行器目录进行模式匹配
> - 📊 **默认定价** - 基于操作系统的备用方案
>
> 有关详细信息，请参阅 [配置指南](docs/CONFIGURATION.md#enhanced-runner-cost-detection)。
#### analyze_runner_utilization
分析运行器利用率和效率。

参数:

org_name: 组织名称（如果设置了 GITHUB_ORG，则可选）
runner_type: 'self-hosted' | 'github-hosted' | 'all'
include_costs: 包括成本分析（默认：true）

#### get_actions_cache_analytics
分析 Actions 缓存使用情况和效率。

参数:

org_name: 组织名称（如果设置了 GITHUB_ORG，则可选）
repo_name: 特定仓库（可选）
timeframe: '24h' | '7d' | '30d'

#### generate_cost_optimization_report
生成可操作的成本优化建议。

参数:

org_name: 组织名称（如果设置了 GITHUB_ORG，则可选）
include_recommendations: 包括可操作的建议（默认：true）
target_savings_percentage: 目标节省百分比（5 - 50，默认：20）

</details>
<details>
<summary>🔍 工作流洞察和团队生产力</summary>
#### get_workflow_insights
获取工作流洞察，检测瓶颈。

参数:

org_name: 组织名称（如果设置了 GITHUB_ORG，则可选）
repo_name: 仓库名称（必需）
workflow_name: 工作流名称或文件名（必需）
analyze_dependencies: 分析作业依赖关系（默认：true）

#### get_team_productivity_metrics
根据 Actions 和提交数据分析团队生产力。

参数:

org_name: 组织名称（如果设置了 GITHUB_ORG，则可选）
team_slug: 团队 slug（可选）
include_individuals: 包括个人指标（默认：false）
timeframe: '7d' | '30d' | '90d'

#### get_compliance_audit_report
生成合规性和安全审计报告。

参数:

org_name: 组织名称（如果设置了 GITHUB_ORG，则可选）
compliance_framework: 'SOC2' | 'ISO27001' | 'HIPAA' | 'PCI-DSS' | 'CUSTOM'
include_secrets_scan: 包括密钥扫描（默认：true，需要 GHAS）

</details>

### 📊 DORA 指标与开发者体验
<details>
<summary>📈 DORA 指标</summary>
#### get_dora_metrics
获取 DORA 指标（部署频率、前置时间、变更失败率、恢复时间）。

参数:

org_name: 组织名称（如果设置了 GITHUB_ORG，则可选）
timeframe: '7d' | '30d' | '90d'
repo_filter: 逗号分隔的仓库列表（可选）

#### get_enhanced_dora_metrics
使用实际的 GitHub 部署 API 获取最准确的 DORA 指标。

参数:

org_name: 组织名称（如果设置了 GITHUB_ORG，则可选）
timeframe: '7d' | '30d' | '90d'
repo_filter: 逗号分隔的仓库列表（可选）

#### get_pull_request_metrics
获取拉取请求指标，包括前置时间、合并率和大小分布。

参数:

org_name: 组织名称（如果设置了 GITHUB_ORG，则可选）
timeframe: '7d' | '30d' | '90d'
repo_name: 特定仓库（可选）
include_stale: 包括陈旧 PR 分析（可选）

#### get_issue_metrics
获取问题指标，包括关闭时间、标签分布和积压健康状况。

参数:

org_name: 组织名称（如果设置了 GITHUB_ORG，则可选）
timeframe: '7d' | '30d' | '90d'
repo_name: 特定仓库（可选）
label_filter: 按标签过滤（可选）

#### get_deployment_metrics
从 GitHub 部署 API 获取部署指标。

参数:

org_name: 组织名称（如果设置了 GITHUB_ORG，则可选）
timeframe: '7d' | '30d' | '90d'
environment: 按环境过滤（可选）
repo_filter: 逗号分隔的仓库列表（可选）

#### get_environment_metrics
分析 GitHub 环境配置，包括保护规则。

参数:

org_name: 组织名称（如果设置了 GITHUB_ORG，则可选）
repo_filter: 逗号分隔的仓库列表（可选）

#### get_discussion_metrics
获取 GitHub 讨论指标，包括回答率和参与度。

参数:

org_name: 组织名称（如果设置了 GITHUB_ORG，则可选）
repo_name: 特定仓库（可选）
timeframe: '7d' | '30d' | '90d'

#### get_merge_queue_metrics
获取跨仓库的合并队列使用情况和采用情况。

参数:

org_name: 组织名称（如果设置了 GITHUB_ORG，则可选）
repo_name: 特定仓库（可选）

</details>

### 🏷️ 自定义属性
<details>
<summary>📋 自定义属性工具</summary>
#### get_org_custom_properties
列出组织的所有自定义属性定义。

参数:

org_name: 组织名称（如果设置了 GITHUB_ORG，则可选）

#### get_custom_properties_analytics
分析自定义属性在仓库中的使用情况和覆盖范围。

参数:

org_name: 组织名称（如果设置了 GITHUB_ORG，则可选）

#### get_repos_by_property
根据自定义属性值查找仓库。

参数:

org_name: 组织名称（如果设置了 GITHUB_ORG，则可选）
property_name: 自定义属性名称（例如 team、tier、compliance）
property_value: 要过滤的属性值（可选）

</details>

### 🏢 企业功能（可选）
<details>
<summary>⚙️ 企业配置</summary>
如果你使用的是 GitHub Enterprise，你可以通过添加以下内容来启用增强功能：
```bash
GITHUB_ENTERPRISE_SLUG=your-enterprise-slug

这将启用：

跨组织计费聚合
企业范围的运行器池
合并审计日志

🔧 开发

🛠️ 构建和运行命令

#### 本地构建 ```bash npm install npm run build docker build -t actions-pulse:local . ``` #### 本地运行（不使用 Docker） ```bash export GITHUB_TOKEN=ghp_your_token export GITHUB_ORG=your-org npm start ```

🤖 使用 GitHub Actions 自动化 DevOps 报告

你可以使用 GitHub Copilot CLI 和 ActionsPulse MCP 服务器在 GitHub Actions 工作流中自动化 DevOps 报告生成。这可以实现每周定时报告、按需分析以及自动创建带有洞察的问题。

工作原理

在工作流运行器中 安装 Copilot CLI。
使用你的 GitHub 令牌 配置 ActionsPulse MCP。
使用提示 运行 Copilot，使用 MCP 工具生成报告。
使用生成的报告 创建问题。

示例工作流

完整的工作示例请参阅。

📄 关键工作流步骤

```yaml - name: Setup MCP config env: GITHUB_TOKEN: ${{ secrets.GH_PAT_DEVOPS }} run: | mkdir -p ~/.copilot printf '%s\n' '{ "mcpServers": { "actions-pulse": { "command": "docker", "args": ["run", "-i", "--rm", "-e", "GITHUB_TOKEN='"$GITHUB_TOKEN"'", "-e", "GITHUB_ORG=your-org", "ghcr.io/tsviz/actions-pulse:latest"], "tools": ["*"] } } }' > ~/.copilot/mcp-config.json

name: Generate DevOps Report env: GITHUB_TOKEN: ${{ secrets.GH_PAT_DEVOPS }} GH_TOKEN: ${{ secrets.GH_PAT_DEVOPS }} run: | copilot --yolo
--disable-builtin-mcps
--additional-mcp-config @$HOME/.copilot/mcp-config.json
--prompt "Use the actions-pulse MCP tools to generate a DevOps report..."

</details>

#### 关键 Copilot CLI 标志
| 标志 | 描述 |
| ---- | ---- |
| `--yolo` | 自动批准所有工具调用（无确认提示） |
| `--disable-builtin-mcps` | 禁用内置的 MCP 服务器（仅使用自定义服务器） |
| `--additional-mcp-config @<file>` | 从文件加载 MCP 服务器配置（使用 `$HOME` 而不是 `~`） |
| `--prompt "<text>"` | Copilot 要执行的提示 |

#### 提示
- 在配置路径中 **使用 `$HOME` 而不是 `~`** — 在 `@file` 参数中，波浪号不会展开。
- **将令牌嵌入参数中** — MCP 配置中的 `env` 块不会将变量传递给 Docker。
- 在 MCP 配置中 **包含 `"tools": ["*"]`** — 此字段是必需的。

### 📚 详细文档
| 文档 | 描述 |
| ---- | ---- |
| [快速开始](docs/QUICKSTART.md) | 5 分钟内上手 |
| [配置指南](docs/CONFIGURATION.md) | 完整的配置参考 |
| [架构](docs/ARCHITECTURE.md) | 系统设计和层级定义 |

#### 示例配置
[examples/](examples/) 目录中提供了现成的配置示例：
| 文件 | 描述 |
| ---- | ---- |
| [mcp-docker.json](examples/mcp-docker.json) | 使用 Docker 的 VS Code MCP 配置 |
| [mcp-local.json](examples/mcp-local.json) | 用于本地开发的 VS Code MCP 配置 |
| [mcp-envfile.json](examples/mcp-envfile.json) | 使用环境文件的 VS Code MCP 配置 |
| [.env.example](examples/.env.example) | 环境变量模板 |
| [inventory.yaml](examples/inventory.yaml) | 仓库清单示例 |
| [devops-config.yaml](examples/devops-config.yaml) | DevOps 观察者配置 |
| [docker-compose.yml](examples/docker-compose.yml) | Docker Compose 部署 |

### 📄 许可证
本项目采用 MIT 许可证。