自动部署

使用AI+MCP自动生成安全CI/CD管道。

现场：https://autodeploy.app

AutoDeploy是一个全栈单仓库，它：

连接到GitHub（OAuth）
分析存储库
生成GitHub操作工作流（AWS/GCP）
将工作流提交到repo
跟踪部署并支持回滚

特性

GitHub OAuth用于安全地链接GitHub帐户并发现仓库/分支。
通过MCP工具进行存储库分析和CI/CD管道生成。
GitHub Actions工作流YAML的提交、版本历史和回滚。
具有重试/回滚支持和工作流调度API的部署日志记录。
React+TypeScript向导UI，用于配置提供者、模板、机密和部署。

技术栈

前端

React+TypeScript
维特
顺风 CSS
客户状态（Client State）

后端

Node.js（ESM）
快速
Zod（工具输入验证）
PostgreSQL（可选通过Supabase）

集成

GitHub OAuth
GitHub操作（工作流生成+提交、历史记录/回滚）
GCP云运行+工件注册表（工作负载身份联合/OIDC）
AWS OIDC（角色发现/选择）

建筑

后端

后端位于 server/ 并且是一个暴露REST端点和MCP风格工具路由器的Express应用程序（ESM）。

关键切入点：

server/server.js –启动Express应用程序、中间件和路由。

重要路线组包括：

GET /health -基本健康检查（用于烟雾测试）。
GET /db/ping –通过以下方式检查数据库连接 healthCheck() 在 server/db.js.
/auth/github/* –GitHub OAuth流加 /auth/github/me 检查。
/auth/local/*, /auth/google/* –额外的身份验证流。
/api/me –会话自省（使用 requireSession).
/users, /connections –由Postgres支持的基本用户和连接CRUD。
/deployments/* –部署日志API，包括重试、回滚和工作流调度。
/agent/* –更高级别的“向导”编排端点。
/mcp/v1/* –MCP工具外观（见下文）。
/pipeline-sessions/* –由Supabase表支持的多步骤管道向导。
/api/rag/* –由Pinecone+Supabase支持的存储库RAG API（GitHub+zip摄取、查询、日志）；看见 server/src/RAG_API_Contracts.md 对于完整的合同。
/api/connections –Secrets步骤使用的GitHub连接状态端点，用于确认GitHub令牌存在并且对所选仓库具有写访问权限。
/api/secrets/github/* –GitHub Actions secrets存在+secrets步骤用于检查和创建的upstart端点 AWS_ROLE_ARN （repo/env级别），而不公开值。

后端需要在中配置Postgres数据库（例如，通过Supabase连接字符串） server/db.js.

MCP工具

工具已在中注册 server/tools/index.js 并通过暴露 server/routes/mcp.js 在 /mcp/v1/:tool_name.

每个工具定义：

一 input_schema （佐德）
一 handler 函数
repo, repo_reader → 存储库发现和分支列表。
pipeline_generator → 综合了CI/CD工作流YAML。
oidc, oidc_adapter → 处理AWS OIDC角色和相关配置。
github, github_adapter → GitHub自动化（例如，文件更新、工作流调度）。
gcp, gcp_adapter, scaffold, scaffold_generator → GCP特定的工作流程脚手架。
rag_ingest_zip, rag_ingest_github, rag_query_namespace, rag_get_logs → MCP v2和 /api/rag.

每个工具定义一个 input_schema （Zod）和a handler 功能。这 mcp 路线：

注射 user_id 和 github_username 从本届会议开始。
使用工具的模式验证输入。
使响应正常化 { success: true/false, data | error }.

注：自动部署着陆营销站点和文档现在直接调用这些MCP v1端点进行实时演示（例如。， repo_reader 和 pipeline_history)当指向同一后端时，更改为 /mcp/v1/* 应该保持v1信封和合约的稳定。

前端

前端生活在 client/ 是用Vite构建的React+TypeScript应用程序。

关键要素：

页面/路线： client/src/pages, client/src/routes
state: 状态 stores in client/src/store
API层： client/src/lib/api.ts （休息+ /mcp/v1/* 呼叫）
UI组件： client/src/components
页面和路线 client/src/pages 和 client/src/routes 实现连接/登录流程、配置向导、机密管理、Jenkins页面、仪表板和404。
状态 stores in client/src/store （例如。， usePipelineStore, useWizardStore, useDeployStore, useAuthStore, useConfigStore)保存向导选择、身份验证/会话信息、管道生成结果、机密/飞行前状态和部署数据。
client/src/lib/api.ts 封装REST和MCP调用，处理GitHub OAuth重定向，缓存AWS角色和仓库列表，并编排管道提交和回滚。
UI组件下 client/src/components 包括共享图元(ui/)，布局和导航(common/)，向导步骤(wizard/)，以及仪表板小部件(dashboard/).

在开发中，前端通过Vite-dev服务器代理与后端通信：

BASE = import.meta.env.VITE_API_BASE || "/api"
在开发中， BASE 通常是 /api，它被代理到Express后端。
SERVER_BASE 源自于 BASE 对于直接 /mcp/v1/* 和 /auth/* 电话。

入门指南

快速启动环境检查表（最低限度的本地设置）

对于基本的本地设置（GitHub登录+Postgres+向导UI），您至少需要：

DATABASE_URL –Postgres连接字符串。
PORT –可选，默认为 3000.
GITHUB_CLIENT_ID –从您的GitHub OAuth应用程序。
GITHUB_CLIENT_SECRET –从您的GitHub OAuth应用程序。
GITHUB_OAUTH_REDIRECT_URI –通常 http://localhost:3000/auth/github/callback 对于本地开发者。
FRONTEND_URL –通常 http://localhost:5173/connect 对于本地开发者。
GITHUB_OAUTH_SCOPES –例如。 repo workflow read:user user:email.
JWT_SECRET –随机秘密字符串（用于会话）。
SESSION_SECRET –AWS/会话流的随机秘密字符串。
SUPABASE_URL –您的Supabase项目URL。
SUPABASE_SERVICE_ROLE –支持服务角色键。

可选，但建议用于完整的向导功能：

OPENAI_API_KEY –启用AI向导代理。

一旦这些设置在 .env 在repo根目录下，您可以如下所述运行后端和前端。

先决条件

Node.js+npm
Postgres（例如，Supabase连接字符串）
GitHub OAuth应用程序凭据

安装

从repo根目录：

npm install

前端依赖关系：

cd client
npm install

运行（后端）

从repo根目录：

# watch mode (Express + Nodemon)
npm run dev

# production mode
npm start

后端正在监听 PORT （默认值 3000).

运行（前端）

自 client/:

npm run dev

Vite-dev服务器默认为端口 5173.

MCP模拟核心+代理（本地）

可用于开发没有真正MCP核心的MCP集成，以及单独练习AI向导。

低级别MCP代理

cd server

# 1) Start mock MCP core (expects Bearer dev-key-123)
node src/scripts/mockMcp.js

# 2) Run low-level MCP client against the mock core
node src/agents/mcpAgent.js

示例 .env 值：

MCP_URL=http://localhost:7070
MCP_API_KEY=dev-key-123

向导代理（CLI+HTTP）

赋予力量的AI巫师 /agent/wizard 和 /agent/wizard/ai 住在 server/agent/wizardAgent.js.

直接从repo根运行它以进行快速实验：

cd server
node agent/wizardAgent.js "List my repositories"

要通过HTTP从正在运行的后端调用向导，请POST到 /agent/wizard/ai 通过身份验证 mcp_session 饼干：

curl -X POST http://localhost:3000/agent/wizard/ai \
  -H "Content-Type: application/json" \
  -H "Cookie: mcp_session=YOUR_SESSION_TOKEN" \
  -d '{
    "prompt": "Generate a pipeline for owner/repo",
    "repoUrl": "https://github.com/owner/repo",
    "provider": "aws",
    "branch": "main"
  }'

看 server/agent/api_calls_doc.md 和 server/agent/wizardAgent_prompts.md 更多示例。

环境配置

后端使用 dotenv 以及环境变量。如果你分叉这个仓库并想要一个完全正常工作的设置，你需要配置以下变量组。

1.核心后端+数据库（必填）

DATABASE_URL –Postgres连接字符串

- 例子： postgresql://USER:PASSWORD@HOST:5432/DB_NAME - 用于 server/db.js 创建连接池。

PORT –Express服务器的HTTP端口（默认值： 3000).

2.GitHub OAuth（登录+访问GitHub需要）

创建GitHub OAuth应用程序并配置：

GITHUB_CLIENT_ID –OAuth应用程序客户端ID。
GITHUB_CLIENT_SECRET –OAuth应用程序客户端机密。
GITHUB_OAUTH_REDIRECT_URI –必须与GitHub OAuth应用程序中配置的回调URL匹配。

- 本地开发人员： http://localhost:3000/auth/github/callback - 生产： https://your-backend.example.com/auth/github/callback

GITHUB_OAUTH_SCOPES –建议： repo workflow read:user user:email.
FRONTEND_URL –成功登录后重定向到哪里。

- 本地开发人员： http://localhost:5173/connect - 应该指向你的前端 /connect 路线。

JWT_SECRET –用于签署的秘密 mcp_session cookie和其他令牌。

这些都是有线的 server/routes/auth.github.js 并且是GitHub登录和提取repo数据所必需的。

3.身份验证/会话（必填）

SESSION_SECRET –某些AWS身份验证流使用的遗留/会话密钥。
JWT_SECRET –（与上述相同）由以下人员使用 requireSession 以及令牌加密。

在任何非本地环境中，对两者都使用强随机值。

4.Supabase（如果使用内置数据库模式，则需要）

AutoDeploy需要一个Postgres数据库，许多用户/会话功能都需要一个Supabase项目：

SUPABASE_URL –您的Supabase项目URL。
SUPABASE_SERVICE_ROLE –Supabase服务角色密钥（保守这个秘密！）。

这些内容已被阅读 server/lib/requireSession.js 加载用户记录。

5.OpenAI/MCP向导（可选但推荐）

如果你想使用AI“向导”流程（LLM支持的建议、回购分析等）：

OPENAI_API_KEY –使用的OpenAI API密钥 server/agent/wizardAgent.js.

此外，在正常HTTP会话之外运行工具/代理时，您可以提供：

MCP_SESSION_TOKEN –代表用户的预先发布的JWT；被...使用 pipeline_generator 和 wizardAgent 当没有饼干的时候。

获得a MCP_SESSION_TOKEN 在地方发展方面：

通过UI登录，然后复制 mcp_session 从浏览器devtools中获取cookie值并将其粘贴到您的 .env 作为 MCP_SESSION_TOKEN=....
或者调用经过身份验证的端点（例如 GET /api/me)从浏览器中重新使用 mcp_session 后端发出的cookie。

如果没有这些，核心后端仍将运行，但向导代理将被禁用。

6.GitHub令牌覆盖（可选）

默认情况下，AutoDeploy使用存储在数据库中的每个用户的GitHub OAuth令牌。对于演示或单用户设置，您可以使用个人访问令牌覆盖此设置：

GITHUB_PAT_OVERRIDE –设置时，所有GitHub API调用都使用此PAT，而不是每个用户的令牌。

7.Google/GCP OAuth（可选，仅用于GCP集成）

如果您想连接Google Cloud（用于GCP工作流和凭据）：

GOOGLE_CLIENT_ID –谷歌OAuth客户端ID。
GOOGLE_CLIENT_SECRET –谷歌OAuth客户端机密。
GOOGLE_REDIRECT_URI –必须与Google OAuth客户端中配置的重定向URI匹配。

- 本地开发人员： http://localhost:3000/auth/google/callback - 生产： https://your-backend.example.com/auth/google/callback

这些用于 server/tools/google_adapter.js 以存储加密的GCP令牌。

8.MCP核心（可选/高级）

如果您正在运行一个单独的MCP核心，并希望后端直接与之通信：

MCP_URL –MCP核心的基本URL（默认 http://localhost:7000).
MCP_API_KEY –该核心所期望的API密钥。

这些主要用于开发路径（例如，模拟MCP核心 server/src/scripts/mockMcp.js).

数据库设置

AutoDeploy需要一个Postgres数据库（通常通过Supabase）。要重新创建此项目使用的核心架构，请执行以下操作：

确保 DATABASE_URL 在你的 .env 指向您的Postgres实例。
应用架构文件：

psql "$DATABASE_URL" -f server/db/schema.sql

这将创建 users, connections, deployment_logs, pipeline_versions, aws_connections, aws_device_sessions, pipeline_sessions, pipeline_events，以及 github_repos AutoDeploy使用的表（以及一些支持类型和索引）。

如果您正在使用Supabase，您还可以粘贴以下内容 server/db/schema.sql 进入Supabase SQL编辑器并运行一次。

AWS OIDC设置

当你选择 亚马逊云服务 AutoDeploy生成GitHub Actions工作流，这些工作流通过GitHub OIDC承担IAM角色，而不是使用长期访问密钥。

高级步骤：

创建一个信任的IAM角色 token.actions.githubusercontent.com 身份提供者和允许 sts:AssumeRoleWithWebIdentity.
限制信任策略 Condition 所以 sub （subject）与您的回购和分支匹配（例如， repo:owner/repo-name:ref:refs/heads/main).
授予该角色部署应用程序所需的权限（例如S3、ECS或Lambda，具体取决于您如何将AWS与工作流/工具连接起来）。
将角色ARN暴露给您的工作流（例如通过GitHub secret，如 AWS_ROLE_ARN)并在配置AWS时在AutoDeploy向导中选择它。

查看MCP的可视图→ AWS流和信任策略示例，请参阅 server/tools/MCP_AWS_Deployment_Flow.md.

GCP云运行使用情况

AutoDeploy生成什么

当您选择 谷歌云平台 AutoDeploy生成GitHub Actions工作流，该工作流：

构建Docker镜像并将其推送到GHCR
使用以下方式向Google Cloud进行身份验证 工作负载身份联合会（OIDC）
将图像推送到 工件注册表
部署 云运行 服务

回购先决条件

推荐的仓库布局：

server/ （后端）
client/ （前端）

AutoDeploy可以从仪表板将Dockerfiles脚手架到这些文件夹中。

所需的GitHub操作机密

将这些设置为 存储库机密 （GitHub仓库→ 设置→ 秘密和变量→ 行动）：

GCP_PROJECT_ID
GCP_REGION
GCP_WIF_PROVIDER （完整的工作负载身份提供程序资源名称）
GCP_DEPLOY_SA_EMAIL （服务帐户电子邮件）

生成+提交工作流

在AutoDeploy UI中：选择目标仓库+分支。
首选配置:

- 集 提供者=GCP - 选择阶段（构建/部署） - 可以选择覆盖Cloud Run服务名称、docker上下文和映像名称。

点击 生成管道.
首选 仪表盘:

- 步骤1：生成/提交Dockerfiles到 server/ + client/ （如果需要） - 步骤2：将生成的工作流YAML提交到仓库

故障排除

GHCR推送被拒绝（许可_拒绝：write_package）

如果工作流推送失败 ghcr.io/*:

确保回购允许 工作流权限→ 读写
检查目标容器映像名称的GitHub包权限
考虑使用特定于repo的映像名称以避免冲突

WIF身份验证失败（未授权_客户端/属性条件）

这表示您的工作负载身份提供程序或服务帐户IAM绑定拒绝了GitHub OIDC令牌。

验证提供者的属性条件是否与仓库匹配（例如。 owner/repo)以及从中部署的分支
验证服务帐户授权 工作负载身份用户 到正确的主体集/主体

测试

运行烟雾测试（后端必须在本地运行）：

npm test

这运行 node test/smoke.test.js，它调用 GET /health 并期待 { ok: true }.

附加测试：

# Run authorization tests for Workflow Copilot / RAG gating
node --test test/authorization.test.js

这些包括：

isPro(user) 免费用户、专业用户和测试版专业用户的行为。
can(user, Actions.USE_AGENT) （试剂+RAG门控）vs can(user, Actions.USE_MCP_TOOL) （所有经过身份验证的用户都可以访问MCP）。

附加后端测试

node --test server/tests/pipelineGeneratorYaml.test.js -理智检查 pipeline_generator 始终为主模板发出语法有效的GitHub Actions YAML(node_app, python_app).这可以防止压痕/with: 映射回归。

项目结构

AutoDeploy/
├── client/              # React + TypeScript + Vite frontend
├── server/              # Express backend, MCP tools, auth, deployment logging
├── test/                # smoke test(s)
├── package.json         # root scripts (dev/start/test)
└── client/package.json  # frontend scripts (dev/build/lint/preview)

Repo家政服务

大多数内部Markdown文档（设计文档、技术说明等）都有意不使用git进行跟踪。默认情况下，只有root README.md 和 client/README.md 进行版本控制以保持回购的精简。

许可证

ISC——请参阅 LICENSE 文件全文。

您可以根据ISC许可证的条款自由克隆、修改和自托管AutoDeploy。如果你在上面构建了一些东西，那么你的文档或UI中的归因是值得赞赏的，但不是必需的。

该项目与第三方服务（例如GitHub、OpenAI和各种云提供商）集成。您有责任遵守他们各自的服务条款，并负责保护您配置的任何API密钥和机密。

AutoDeploy按“原样”提供，不提供任何保证。在将代码、环境变量和数据库模式用于生产环境之前，请先对其进行审查，并确保其符合组织的安全性、合规性和数据处理要求。

如果您发现安全问题，请避免提交公开问题，而是私下联系维护人员（例如通过存储库所有者GitHub个人资料中列出的电子邮件）。

欢迎通过pull请求和issues进行贡献。通过贡献，您同意您的贡献将根据与此存储库相同的ISC许可证获得许可。

Auto Deploy

快速接入

详细介绍