greenbump 0.4.0 → 0.6.0

package/action.yml

@@ -1,76 +0,0 @@
-name: "greenbump"
-description: "Upgrade a dependency and let an AI agent fix the code it breaks, then open a green PR."
-branding:
-  icon: "refresh-cw"
-  color: "green"
-inputs:
-  anthropic-api-key:
-    description: "Your Anthropic API key (uses Claude). You pay for the tokens a fix costs."
-    required: false
-  deepseek-api-key:
-    description: "Your DeepSeek API key (uses DeepSeek, OpenAI-compatible). Provide this OR anthropic-api-key."
-    required: false
-  github-token:
-    description: "Token used to push the branch and open the PR. Use a PAT if you want CI to run on the PR."
-    required: false
-    default: ${{ github.token }}
-  dependency:
-    description: "Dependency to upgrade. Omit to pick the most-outdated one."
-    required: false
-  to:
-    description: "Target version (default: latest)."
-    required: false
-  ecosystem:
-    description: "Dependency ecosystem (npm, poetry, cargo, maven, …). Auto-detected if omitted."
-    required: false
-  build-cmd:
-    description: "Override the build command, e.g. \"make build\"."
-    required: false
-  test-cmd:
-    description: "Override the test command, e.g. \"make test\"."
-    required: false
-  provider:
-    description: "Model provider preset (openai, anthropic, deepseek, groq, …). Auto-detected if omitted."
-    required: false
-  model:
-    description: "Model id for the fix agent (default: per provider)."
-    required: false
-  base-url:
-    description: "Custom OpenAI-compatible endpoint (or override a preset)."
-    required: false
-  api-key:
-    description: "API key for --provider/--base-url. Prefer anthropic-api-key/deepseek-api-key for the built-in presets."
-    required: false
-  max-rounds:
-    description: "Max fix-loop rounds (caps token spend)."
-    required: false
-    default: "15"
-  max-tokens:
-    description: "Hard cap on total tokens spent by the fix loop; stops and flags the PR for review on overrun."
-    required: false
-  base-branch:
-    description: "Base branch for the PR (default: the triggering branch)."
-    required: false
-  review-label:
-    description: "Label added to the PR when it needs a human look (test file touched, or unverifiable). Auto-created if it doesn't exist."
-    required: false
-    default: "needs-review"
-  report-file:
-    description: "Write a JSON report of the run to this path."
-    required: false
-outputs:
-  status:
-    description: "One of: pr-opened, pr-needs-review, no-changes, unfixed, skipped."
-  pr-url:
-    description: "URL of the opened PR, if any."
-  dependency:
-    description: "The dependency that was upgraded."
-  from:
-    description: "Version before the upgrade."
-  to:
-    description: "Version after the upgrade."
-  fixed:
-    description: "Whether build + tests ended up green."
-runs:
-  using: "node20"
-  main: "action-dist/index.cjs"

package/competitive-analysis.md

@@ -1,304 +0,0 @@
-# greenbump 竞品深度分析
-
-## 一、核心定位差异
-
-### greenbump
-**定位**：AI 驱动的依赖升级 + 代码修复工具  
-**核心价值**：自动化「升级→失败→修复」全流程  
-**目标用户**：需要快速迭代依赖升级的团队，尤其是多语言/多框架项目
-
-### Dependabot
-**定位**：依赖版本监控 + PR 自动化  
-**核心价值**：零配置的依赖更新提醒  
-**目标用户**：GitHub 用户，尤其是大规模 repo 管理
-
-### Renovate
-**定位**：企业级依赖管理平台  
-**核心价值**：高度可定制的升级策略 + 批量管理  
-**目标用户**：有复杂升级策略的大型组织（如 monorepo、多团队协作）
-
-### Migratowl
-**定位**：Python 依赖迁移的 AI 助手  
-**核心价值**：沙盒隔离 + LLM 修复（安全性优先）  
-**目标用户**：需要升级高风险 Python 依赖的团队（如金融、医疗）
-
----
-
-## 二、实用性对比矩阵
-
-| 维度 | greenbump | Dependabot | Renovate | Migratowl |
-|------|-----------|------------|----------|-----------|
-| **适用场景** | | | | |
-| 小型项目（<10 依赖） | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ |
-| 中型项目（10-50 依赖） | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
-| 大型 monorepo | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐ |
-| 多语言项目 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐ (Python only) |
-| 遗留代码库 | ⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ |
-| **破坏性升级** | | | | |
-| minor/patch 升级 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
-| major 版本跨越 | ⭐⭐⭐ | ⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐ |
-| 框架级重构 (如 Angular 2→3) | ⭐ | ⭐ | ⭐ | ⭐⭐ |
-| **成本** | | | | |
-| 金钱成本 | 💰 (API 按量付费) | 免费 | 免费/SaaS 订阅 | 💰💰 (API 按量付费) |
-| 时间成本（首次配置） | 5 分钟 | 0 分钟 | 30-60 分钟 | 10 分钟 |
-| 时间成本（每次升级） | 2-10 分钟 | 人工修复 30-120 分钟 | 人工修复 30-120 分钟 | 5-20 分钟 |
-| **可靠性** | | | | |
-| 误修复率（引入新 bug） | 中 (10-20%) | N/A | N/A | 低 (5-10%, 沙盒验证) |
-| 修复成功率（简单升级） | 高 (80-90%) | N/A | N/A | 高 (85-95%) |
-| 修复成功率（复杂升级） | 低 (20-40%) | N/A | N/A | 中 (50-60%) |
-
----
-
-## 三、深度场景分析
-
-### 场景 1：小团队快速迭代（2-5 人，周迭代）
-**需求**：快速升级依赖，不想花时间手动修代码
-
-**推荐**：greenbump ⭐⭐⭐⭐⭐
-- ✅ **优势**：
-  - 零配置启动，`npx greenbump react` 一条命令搞定
-  - 对于简单的 API 重命名（80% 的 minor/patch 升级），5 分钟内修复
-  - 多语言支持（前后端同时升级）
-  - 成本可控（--max-rounds 限制）
-- ⚠️ **风险**：
-  - LLM 可能引入新 bug（需要 code review）
-  - 复杂升级可能浪费 token 还失败
-
-**不推荐**：Renovate（配置复杂度过高，overkill）
-
----
-
-### 场景 2：大型企业 monorepo（100+ 依赖，10+ 团队）
-**需求**：统一管理依赖版本，批量升级，严格审批流程
-
-**推荐**：Renovate ⭐⭐⭐⭐⭐
-- ✅ **优势**：
-  - 高级批量策略（按团队、按类型分组升级）
-  - 自动合并安全补丁（配置 automerge）
-  - 与企业 CI/CD 深度集成
-  - 完全免费（self-host）
-- ⚠️ **风险**：
-  - 初期配置成本高（需要专人维护 renovate.json）
-  - 依然需要人工修复每个 breaking change
-
-**辅助工具**：greenbump（针对特定子项目的快速修复）
-
----
-
-### 场景 3：高风险生产环境（金融/医疗，Python 为主）
-**需求**：升级依赖但绝对不能引入新 bug，需要严格验证
-
-**推荐**：Migratowl ⭐⭐⭐⭐⭐
-- ✅ **优势**：
-  - 沙盒隔离验证（K8s 容器 + 真实数据库）
-  - 多轮验证（LLM 修复 → 沙盒测试 → 再修复）
-  - 专注 Python 生态（对 Django/Flask 迁移优化）
-- ⚠️ **风险**：
-  - 成本高（沙盒环境 + Claude API）
-  - 速度慢（每次迭代需要完整沙盒启动）
-  - 只支持 Python
-
-**不推荐**：greenbump（缺少沙盒隔离，风险高）
-
----
-
-### 场景 4：开源项目维护（志愿者，不想花钱）
-**需求**：自动监控依赖更新，社区贡献 PR
-
-**推荐**：Dependabot ⭐⭐⭐⭐⭐
-- ✅ **优势**：
-  - 完全免费
-  - 零配置（GitHub 原生）
-  - 社区熟悉度高（PR 格式标准）
-- ⚠️ **风险**：
-  - 手动修复 breaking change（但开源项目通常有贡献者帮忙）
-
----
-
-## 四、技术实现对比
-
-### 验证可靠性
-| 工具 | 验证方式 | 可信度 | 问题 |
-|------|---------|--------|------|
-| greenbump | 用户的 `npm test` / `build` 脚本 | ⭐⭐⭐ | 依赖测试覆盖率；可能删测试来通过 |
-| Migratowl | 沙盒隔离 + 真实数据库 | ⭐⭐⭐⭐⭐ | 成本高，速度慢 |
-| Dependabot | CI 运行测试（PR 之后） | ⭐⭐⭐⭐ | 需要人工修复才能通过 |
-| Renovate | CI 运行测试（PR 之后） | ⭐⭐⭐⭐ | 同上 |
-
-**greenbump 的验证缺陷**：
-1. 如果项目没测试，greenbump 只能确保"能编译"，无法确保"功能正确"
-2. LLM 可能偷偷注释掉失败的测试（虽然会标记 `needsReview`，但用户可能不看）
-3. 没有沙盒隔离，修复过程中可能污染本地环境
-
-**改进建议**（未来可做）：
-- 添加 `--sandbox` 模式（Docker 隔离）
-- 检测测试文件修改（现在已有 `needsReview` 标记）
-- 集成静态分析（如 TypeScript type check）
-
----
-
-### 模型灵活性
-| 工具 | 支持的模型 | 成本控制 | 离线可用 |
-|------|-----------|---------|---------|
-| greenbump | Claude, DeepSeek, OpenAI, 任意 OpenAI-compatible | ⭐⭐⭐⭐⭐ (--max-rounds, --max-tokens) | ❌ |
-| Migratowl | Claude only | ⭐⭐⭐ (固定策略) | ❌ |
-| GitHub Copilot Workspace | GitHub 模型 | ⭐⭐ (订阅制) | ❌ |
-
-**greenbump 的独特优势**：
-- 可以用 DeepSeek（便宜 10 倍）跑简单升级
-- 可以用本地 Ollama 模型（完全免费，但效果差）
-- 严格的成本上限（不会因为 LLM 死循环烧光预算）
-
----
-
-## 五、真实世界实用性评估
-
-### greenbump 的「甜蜜点」场景
-✅ **最适合**：
-1. **简单 API 重命名**（如 `lodash.get()` → `_.get()`）
-   - 成功率：90%+
-   - 时间节省：30 分钟 → 3 分钟
-   
-2. **小规模依赖升级**（1-5 个文件改动）
-   - 成功率：70-80%
-   - 成本：$0.10-$0.50 per fix
-   
-3. **有完善测试的项目**
-   - LLM 可以信任测试输出
-   - 误修复会被立即发现
-
-⚠️ **不适合**：
-1. **大规模重构**（如 Webpack 4 → 5，涉及 50+ 文件）
-   - LLM 上下文不够，会遗漏文件
-   - 建议：人工升级 + greenbump 修细节
-   
-2. **没测试的项目**
-   - greenbump 无法验证正确性
-   - 建议：先写测试，或用 Dependabot
-
-3. **Runtime-only 的 bug**（如数据库查询逻辑变化）
-   - 测试通过但生产环境炸
-   - 建议：人工 review + staging 验证
-
----
-
-### Renovate 的「甜蜜点」场景
-✅ **最适合**：
-1. **大型 monorepo**（统一管理 100+ 依赖）
-2. **自动合并安全补丁**（配置 automerge 规则）
-3. **复杂升级策略**（如"周一升级 dev deps，周五升级 prod deps"）
-
-⚠️ **不适合**：
-1. **小项目**（配置成本 > 收益）
-2. **需要快速迭代**（PR 创建后依然要人工修代码）
-
----
-
-### Migratowl 的「甜蜜点」场景
-✅ **最适合**：
-1. **高风险生产环境**（金融、医疗）
-2. **Major 版本跨越**（如 Django 2 → 4）
-3. **缺少测试但不能出错**（沙盒验证兜底）
-
-⚠️ **不适合**：
-1. **非 Python 项目**
-2. **预算有限**（成本是 greenbump 的 3-5 倍）
-3. **快速迭代**（沙盒启动慢）
-
----
-
-## 六、成本-收益分析
-
-### 假设场景：一个中型 React + Node.js 项目，50 个依赖，每月升级 5 个
-
-#### 方案 1：纯人工（Dependabot 提醒）
-- **时间成本**：5 个依赖 × 平均 1 小时 = 5 小时/月
-- **金钱成本**：$0
-- **风险**：人工错误，遗漏升级
-- **年化成本**：60 小时 = $6,000（按 $100/小时）
-
-#### 方案 2：greenbump
-- **时间成本**：5 个依赖 × 平均 10 分钟（跑 + review）= 50 分钟/月
-- **金钱成本**：5 次 × $0.30 = $1.50/月（DeepSeek）
-- **风险**：10% 误修复率，需要 code review
-- **年化成本**：10 小时 + $18 = $1,018
-
-**节省**：$4,982/年（83% 时间节省）
-
-#### 方案 3：Renovate（自动合并安全补丁）
-- **时间成本**：
-  - 初期配置：8 小时（一次性）
-  - 每月维护：30 分钟（调整规则）
-  - 人工修复 breaking change：3 个 × 1 小时 = 3 小时/月
-- **金钱成本**：$0（self-host）
-- **年化成本**：8 + 36 + 6 = 50 小时 = $5,000
-
-**对比**：greenbump 在中型项目上最具成本效益
-
----
-
-## 七、综合推荐
-
-### 如果你是...
-
-**1. 创业公司/小团队**（<10 人）
-→ **greenbump** ⭐⭐⭐⭐⭐  
-理由：时间就是钱，快速迭代最重要
-
-**2. 大型企业**（100+ 依赖，多团队）
-→ **Renovate** (主) + **greenbump** (辅)  
-理由：Renovate 管策略，greenbump 修代码
-
-**3. 开源项目维护者**
-→ **Dependabot** ⭐⭐⭐⭐⭐  
-理由：免费 + 社区熟悉
-
-**4. 高风险生产环境**（金融/医疗，Python）
-→ **Migratowl** ⭐⭐⭐⭐⭐  
-理由：沙盒验证是硬需求
-
-**5. 遗留代码库**（无测试，怕炸）
-→ **人工升级** + code review  
-理由：任何自动化工具都不可信
-
----
-
-## 八、greenbump 的改进空间
-
-### 当前最大痛点
-1. **验证可靠性不足**
-   - 问题：依赖用户测试覆盖率
-   - 解决：添加 `--sandbox` Docker 隔离模式
-
-2. **复杂升级成功率低**
-   - 问题：LLM 上下文有限，大型重构会遗漏
-   - 解决：引入「多阶段升级」（先升级配置，再升级代码）
-
-3. **成本不透明**
-   - 问题：用户不知道一次升级会花多少钱
-   - 解决：添加 `--estimate` 预估模式
-
-### 未来可做的功能
-1. **学习模式**：记录成功的修复模式，下次直接套用（不调 LLM）
-2. **团队共享**：同一个依赖的升级经验，团队内复用
-3. **Rollback 机制**：如果 PR merge 后生产环境炸了，一键回滚
-
----
-
-## 结论
-
-**greenbump 的核心价值**：  
-在「零配置」和「高度可定制」之间找到平衡，用 LLM 自动化了「升级后手动修代码」这个最痛的环节。
-
-**适用性**：⭐⭐⭐⭐  
-- 对小型/中型项目（<50 依赖）极度友好
-- 对大型 monorepo 需要配合 Renovate 使用
-- 对高风险场景需要人工 review 兜底
-
-**实用性**：⭐⭐⭐⭐  
-- 时间节省：60-80%（vs 纯人工）
-- 成本可控：$0.10-$0.50 per fix（DeepSeek）
-- 风险可控：needsReview 标记 + code review
-
-**最大竞争优势**：  
-唯一支持「多语言 + 多模型 + 实际修代码」的工具。Dependabot/Renovate 只管版本号，Migratowl 只支持 Python，greenbump 填补了这个空白。

package/examples/greenbump.yml

@@ -1,37 +0,0 @@
-# Copy this to .github/workflows/greenbump.yml in your repo.
-# Example GitHub Actions workflow for greenbump
-# See https://github.com/shidesheng0218/greenbump for full documentation
-name: greenbump
-
-on:
-  schedule:
-    - cron: "0 6 * * 1" # every Monday 06:00 UTC
-  workflow_dispatch: # or run it by hand, optionally naming a dependency
-    inputs:
-      dependency:
-        description: "Dependency to upgrade (blank = most outdated)"
-        required: false
-
-permissions:
-  contents: write
-  pull-requests: write
-
-jobs:
-  bump:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 20
-
-      - run: npm ci
-
-      - uses: shidesheng0218/greenbump@v0
-        with:
-          anthropic-api-key: ${{ secrets.ANTHROPIC_API_KEY }}
-          dependency: ${{ inputs.dependency }}
-          # Optional: use a PAT instead of the default token if you want
-          # the generated PR to trigger your CI workflows.
-          # github-token: ${{ secrets.GREENBUMP_PAT }}

package/examples/legacy-repo/package.json

@@ -1,12 +0,0 @@
-{
-  "name": "legacy-repo",
-  "version": "1.0.0",
-  "description": "Sample repo with a deliberately outdated dependency, for greenbump e2e testing.",
-  "private": true,
-  "scripts": {
-    "test": "node test.js"
-  },
-  "dependencies": {
-    "uuid": "3.4.0"
-  }
-}

package/examples/legacy-repo/test.js

@@ -1,17 +0,0 @@
-const assert = require("node:assert");
-const { newId } = require("./src/id.js");
-
-// A real test that asserts behaviour — greenbump must NOT weaken this to pass.
-const id = newId();
-assert.strictEqual(typeof id, "string", "id must be a string");
-assert.match(
-  id,
-  /^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/,
-  "id must be a valid UUID",
-);
-
-const a = newId();
-const b = newId();
-assert.notStrictEqual(a, b, "ids must be unique");
-
-console.log("ok - newId() returns unique valid UUIDs");

package/examples/multi-file-repo/models/todo.js

@@ -1,8 +0,0 @@
-// Breaks on uuid v7+: the `uuid/v4` subpath import was removed.
-const uuidv4 = require("uuid/v4");
-
-function createTodo(title) {
-  return { id: uuidv4(), title, done: false };
-}
-
-module.exports = { createTodo };

package/examples/multi-file-repo/models/user.js

@@ -1,11 +0,0 @@
-// Breaks on uuid v7+: the `uuid/v4` subpath import was removed.
-// Note the different local name (`generateId`) from models/todo.js —
-// a fix agent that patches one call site and re-runs tests will only
-// see this one break AFTER fixing todo.js, one at a time.
-const generateId = require("uuid/v4");
-
-function createUser(name) {
-  return { id: generateId(), name };
-}
-
-module.exports = { createUser };

package/examples/multi-file-repo/package.json

@@ -1,12 +0,0 @@
-{
-  "name": "multi-file-repo",
-  "version": "1.0.0",
-  "description": "Sample repo where one dependency upgrade breaks 3 separate files, for greenbump e2e testing of search_code.",
-  "private": true,
-  "scripts": {
-    "test": "node test.js"
-  },
-  "dependencies": {
-    "uuid": "3.4.0"
-  }
-}

package/examples/multi-file-repo/services/session.js

@@ -1,9 +0,0 @@
-// Breaks on uuid v7+: the `uuid/v4` subpath import was removed.
-// Yet another local name (`newUUID`) — third independent call site.
-const newUUID = require("uuid/v4");
-
-function startSession(userId) {
-  return { token: newUUID(), userId, startedAt: Date.now() };
-}
-
-module.exports = { startSession };

package/examples/multi-file-repo/test.js

@@ -1,19 +0,0 @@
-const assert = require("node:assert");
-const { createTodo } = require("./models/todo.js");
-const { createUser } = require("./models/user.js");
-const { startSession } = require("./services/session.js");
-
-const UUID_RE = /^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/;
-
-const todo = createTodo("write tests");
-assert.match(todo.id, UUID_RE, "todo id must be a valid UUID");
-assert.strictEqual(todo.title, "write tests");
-
-const user = createUser("ada");
-assert.match(user.id, UUID_RE, "user id must be a valid UUID");
-
-const session = startSession(user.id);
-assert.match(session.token, UUID_RE, "session token must be a valid UUID");
-assert.strictEqual(session.userId, user.id);
-
-console.log("ok - todo, user, and session all generate valid UUIDs");