Skip to content

Releases: fengyincheng/patchpawwww

v0.3.0 — Docker 正式支持

Choose a tag to compare

@fengyincheng fengyincheng released this 23 Sep 10:06

🐳 Docker 部署

新增:

  • Dockerfile
  • compose.yaml
  • Docker healthcheck
  • Docker 部署与升级文档
  • GHCR 镜像发布流程
  • linux/amd64 与 linux/arm64 多架构构建
  • native → Docker 迁移说明

PatchPaw 容器默认以非 root 用户运行,运行数据统一保存在:

/var/lib/patchpaw

Compose 使用持久化 volume 保存数据库、Memory、仓库缓存、worktree、run、snapshot、outbox 等运行数据。

🔐 更安全的容器默认配置

官方 Docker 配置默认:

  • 使用非 root 用户运行
  • 不挂载 Docker socket
  • 不启用 privileged
  • 启用 no-new-privileges
  • GitHub App Private Key 通过只读挂载提供
  • 使用 Tini 管理容器 PID 1
  • 支持 SIGTERM 优雅停止
  • 提供容器健康检查

🧰 支持扩展项目工具链

官方基础镜像只提供 PatchPaw 运行所需的基础环境:

  • Node.js / npm
  • Git
  • CA certificates
  • PatchPaw Web UI

Python、Java、Rust、Go、Android SDK、.NET 等项目环境不会全部塞进基础镜像。

如果目标仓库需要额外工具链,可以直接基于官方镜像构建自己的派生镜像:

FROM ghcr.io/fengyincheng/patchpaw:<version>

USER root

# 安装项目需要的工具链

USER patchpaw

仓库中也新增了扩展镜像示例。

⚙️ 容器运行支持

为了支持容器部署,本版本同时调整了运行时配置:

  • .env 不再是强制存在的启动文件
  • 支持通过环境变量直接注入配置
  • 新增可配置监听地址
  • native 部署仍默认监听 127.0.0.1
  • Docker 内监听 0.0.0.0
  • tsx 调整为正式运行依赖

已有 runtime 在 Docker 启动时仍会执行版本化 builtin migration。

该 migration 只会在 PatchPaw 服务正式启动时执行;backup、observer、shell 等运维命令不会因为启动 entrypoint 而隐式修改数据库。

📦 镜像发布

Docker 镜像通过 GitHub Container Registry 发布:

ghcr.io/fengyincheng/patchpaw

稳定 Release 将提供版本 tag,并同时构建:

linux/amd64
linux/arm64

生产环境建议固定具体版本,而不是长期依赖 latest

📖 文档

README 新增 Docker 快速开始,并新增完整的:

docs/DOCKER.md

其中包含:

  • 从零部署
  • 数据持久化
  • Secret 管理
  • 升级
  • 备份
  • 工具链扩展
  • native → Docker 迁移
  • Windows / macOS Docker Desktop 使用边界

v0.2.1 — 稳定性与生命周期修复

Choose a tag to compare

@fengyincheng fengyincheng released this 21 Sep 08:51

🐛 修复:修复 Multi-SCM 生命周期中 project_id 传递、通知持久化与失败恢复不完整的问题。
🤖 Agent 契约:修复 CI / Conflict 仍残留旧 structured completion 语义的问题,统一到当前自然语言输出契约。
🧪 测试:修复一批过时测试契约,并补回 workspace 创建后异常时必须清理的回归覆盖。
🛠️ 测试工具:改进串行测试器的分片、断点和 OOM / exit 137 处理,避免低内存环境下误判。

v0.2.0—重构与agent本地观察

Choose a tag to compare

@fengyincheng fengyincheng released this 21 Sep 03:26

👀 Agent Run 本地观察

新增只读 Agent Observer,可以直接在运行 PatchPaw 的机器上查看 Agent 当前在做什么。

npm run agent:open -- owner/repo 132
npm run agent:open -- --run --replay 20
npm run agent:status -- owner/repo 132
npm run agent:runs -- --failed --limit 50

agent:open 支持:

实时跟随 Agent Run

最近事件回放

--all

--replay N

--compact

--verbose

--json

--wait

同时完善了 Observer 的 Run 解析、等待/附着语义、摘要输出和失败状态展示。

🔀 GitHub / GitLab 统一执行核心

本版本对 Multi-SCM 架构进行了较大调整。

新增完整的:

GitHubAdapter implements ScmAdapter
GitLabAdapter implements ScmAdapter

原先独立维护大量业务逻辑的 GitLab Runner 已缩减为平台入口层,主要负责 GitLab connection、身份、snapshot 和上下文构造。

Task、Approval、Agent 执行、写回、恢复和结束流程不再分别维护两套实现。

🧩 Runner 架构重构

原先较为集中的 Runner 已拆分为更明确的生命周期模块,包括:

pull-request.ts 的职责显著收缩,平台差异进一步集中到 SCM Adapter 与入口层。

这也意味着以后新增共享功能时,不再需要分别给 GitHub 和 GitLab 维护两套生命周期实现。

✅ 新增更细的权限分级——读写(需审批)可在前端web调整

完善并统一了 read_write_approval 的执行流程:

Planning
→ 发布 Plan
→ 等待 /approval
→ 校验审批来源与当前 SCM 状态
→ Approved Write
→ Harness 写回
→ Settlement

✍️ 统一 Writeback

GitHub / GitLab 的写回流程已经收敛为共享实现。

如果 Agent 已经创建 commit,Harness 不会重复提交。

如果 Agent 只修改了工作区但没有 commit,Harness 会负责 commit。

📝 Agent 输出进一步自然语言化

新运行路径继续使用 opaque natural-language / Markdown 作为 Agent 输出。

Review、CI、Conflict、Custom、Repair 等任务不再依赖 Agent 输出固定业务 JSON 才能继续运行。

🧭 Control Plane 收敛

历史内置命令可以迁移到当前结构,同时尽量保留管理员已有的权限和自定义配置。

📬 Communication / Finalization 重构

任务执行完成与“用户是否真正收到消息”继续作为两个独立 durable fact 处理。

🛡️ 可靠性改进

本版本还包含多项运行时和恢复逻辑调整——Agent Turn lifecycle 更明确,Final-answer fallback 独立预算等。


升级说明

本版本主要是内部架构和可靠性升级,没有刻意改变现有命令的产品语义。

已有 GitHub / GitLab 用户可以继续使用原有配置。

新增 Agent Observer 命令可直接使用:

npm run agent:open -- owner/repo <PR/MR>
npm run agent:status -- owner/repo <PR/MR>
npm run agent:runs

v0.1.0 — GitLab 支持与可靠性更新

Choose a tag to compare

@fengyincheng fengyincheng released this 16 Sep 13:04

v0.1.0 — GitLab 支持与可靠性更新

这是 PatchPaw 的首个正式版本 Release。

本次版本重点完善了 GitLab 支持以及任务失败时的可观测性,让 GitLab MR 中的 Agent 执行结果和错误原因更加清晰、可靠。

GitLab

  • 完善 GitLab Merge Request 工作流支持
  • 支持 GitLab 自定义只读与读写命令
  • 完善 GitLab Conflict、Review、Repair 等执行生命周期
  • 增加 GitLab 配置与使用文档

错误处理与可观测性

  • 细分 GitLab 失败类型:认证失败、配置错误、网络或上游服务不可用、协议/响应格式异常、请求被拒绝
  • Provider 429、5xx 等上游错误现在会保留结构化错误信息
  • MR 中会展示真实失败阶段,例如:阶段:repair;状态:provider_unavailable
  • GitLab bootstrap 阶段失败也会持久化 Run、Trace 和 Result 信息
  • 失败通知接入 durable outbox
  • 通知发送失败不会覆盖原始任务错误
  • 通知失败不会导致 Agent 或模型重复执行
  • run_notice_published、run_notice_pending 和 run_notice_failed 现在能够反映真实通知状态
  • GitHub 侧同步修正了通知 Trace 的状态语义

安全与依赖

  • Vite 更新至 7.3.6
  • 当前依赖审计未发现已知 npm 漏洞