|
| 1 | +--- |
| 2 | +name: batch-deps-upgrade |
| 3 | +description: Batch all open Dependabot dependency upgrade PRs into a single PR |
| 4 | +disable-model-invocation: true |
| 5 | +--- |
| 6 | + |
| 7 | +Batch all open Dependabot dependency upgrade PRs into a single PR for this repository. |
| 8 | + |
| 9 | +## Step 1: Discover |
| 10 | + |
| 11 | +Run: gh pr list --repo XRPLF/xrpl-py --label dependencies --state open --limit 500 --json number,title,headRefName,body,url |
| 12 | + |
| 13 | +Parse each PR to extract package names and versions. Dependabot PRs come in two formats: |
| 14 | + |
| 15 | +- **Single-package PRs**: title is `bump <pkg> from <old> to <new>` — parse from title |
| 16 | +- **Grouped PRs**: title is `bump <pkg1> and <pkg2>` with no versions — parse from PR body, which contains a structured list of package updates with version ranges |
| 17 | + |
| 18 | +If any PR can't be parsed from either title or body, flag it for manual review. Build a table of all proposed upgrades. Report the table to the user before proceeding. |
| 19 | + |
| 20 | +## Step 2: Apply all upgrades |
| 21 | + |
| 22 | +1. Create a branch from main: `deps/batch-deps-upgrade-YYYY-QN` (use current year and quarter) |
| 23 | +2. Check for **dependency conflicts** before upgrading. For each proposed upgrade, review `pyproject.toml` constraints and run `poetry show <pkg>` to check if any other dependency pins a version range that would block the upgrade. Mark conflicts as Skipped (dependency conflict: <details>) and do not attempt them. |
| 24 | +3. For each remaining dependency, apply the upgrade: |
| 25 | + - **Direct deps** (listed in `pyproject.toml` under `[tool.poetry.dependencies]` or `[tool.poetry.group.dev.dependencies]`): update the version constraint in `pyproject.toml` to the new version using caret (`^<new_version>`), then run `poetry update <pkg>`. Always update `pyproject.toml` for direct deps — even if the current constraint already allows the new version — so the pinned minimum stays current. |
| 26 | + - **Transitive deps** (not in `pyproject.toml`): run `poetry update <pkg>` to update within the existing constraint range |
| 27 | +4. After all upgrades are applied, run `poetry lock` to regenerate `poetry.lock`. **Do NOT delete `poetry.lock` and regenerate from scratch**. |
| 28 | +5. Run `poetry install` to sync the virtual environment. |
| 29 | +6. Diff `pyproject.toml` and `poetry.lock` against main to classify each Dependabot PR as: |
| 30 | + - Upgraded: version changed |
| 31 | + - No-op: version was already current or newer |
| 32 | +7. If any upgrade changes the public API of the library (new errors, changed return types, removed functionality) and results in a breaking change, add an entry under `## [Unreleased]` in `CHANGELOG.md`. |
| 33 | +8. Verify completeness: every PR from Step 1 must have a status (Upgraded, No-op, or Skipped). If any PR is unaccounted for, stop and report it before proceeding. |
| 34 | + |
| 35 | +## Step 3: Validate |
| 36 | + |
| 37 | +Run the **full validation suite across all Python versions** from the CI matrix. Repeat until everything passes. |
| 38 | + |
| 39 | +### Determine Python versions |
| 40 | + |
| 41 | +Read each workflow file under `.github/workflows/` to determine the Python versions used: |
| 42 | + |
| 43 | +- `.github/workflows/unit_test.yml` — the `unit-test` job uses a matrix of Python versions; the `lint-and-type-check` job uses a single Python version (not a matrix) |
| 44 | +- `.github/workflows/integration_test.yml` — the `integration-test` job uses a matrix of Python versions |
| 45 | +- `.github/workflows/faucet_test.yml` — the `faucet-test` job uses a matrix of Python versions |
| 46 | + |
| 47 | +Extract the exact Python versions from each workflow's `matrix.python-version` array (or the `PYTHON_VERSION` env var for lint). These versions are the source of truth for validation. |
| 48 | + |
| 49 | +### Switching between Python versions |
| 50 | + |
| 51 | +To switch Python versions for testing, use `pyenv` and `poetry`: |
| 52 | + |
| 53 | +```bash |
| 54 | +pyenv install <version> # install if not already present |
| 55 | +pyenv local <version> # set the local Python version |
| 56 | +poetry env use python<version> # point poetry to the correct interpreter |
| 57 | +poetry install # reinstall deps for this interpreter |
| 58 | +``` |
| 59 | + |
| 60 | +Replace `<version>` with the target version (e.g. `3.10`, `3.11`, `3.12`, `3.13`, `3.14`). After running all tests for one version, repeat these steps to switch to the next. |
| 61 | + |
| 62 | +### Validation order |
| 63 | + |
| 64 | +Run validation **in parallel across all Python versions** from the unit test matrix to speed things up. For each Python version, create a separate working directory (e.g. using `git worktree` or by spawning parallel agents) so that each version's virtual environment does not interfere with the others. |
| 65 | + |
| 66 | +For each Python version, run the following in order: |
| 67 | + |
| 68 | +1. **Lint and type-check** (only on the single lint Python version from the `lint-and-type-check` job): |
| 69 | + |
| 70 | + ```bash |
| 71 | + poetry run poe lint |
| 72 | + poetry run mypy --strict --implicit-reexport xrpl |
| 73 | + ``` |
| 74 | + |
| 75 | +2. **Unit tests**: |
| 76 | + |
| 77 | + ```bash |
| 78 | + poetry run poe test_unit |
| 79 | + poetry run coverage report --fail-under=85 |
| 80 | + ``` |
| 81 | + |
| 82 | +3. **Integration tests** (requires a single shared xrpld Docker container — start it once before running integration tests for any Python version): |
| 83 | + - Pre-run cleanup: `docker rm -f xrpld-service 2>/dev/null || true` |
| 84 | + - Start the container: |
| 85 | + ```bash |
| 86 | + docker run \ |
| 87 | + --detach \ |
| 88 | + --publish 5005:5005 \ |
| 89 | + --publish 6006:6006 \ |
| 90 | + --volume "$PWD/.ci-config/:/etc/opt/xrpld/" \ |
| 91 | + --name xrpld-service \ |
| 92 | + rippleci/xrpld:develop --standalone |
| 93 | + ``` |
| 94 | + - Wait for port 6006 with a bounded timeout: |
| 95 | + ```bash |
| 96 | + SECONDS=0 |
| 97 | + until nc -z localhost 6006 || [ $SECONDS -gt 120 ]; do sleep 2; done |
| 98 | + if ! nc -z localhost 6006; then |
| 99 | + echo "Error: xrpld did not start within 120s" |
| 100 | + docker logs xrpld-service |
| 101 | + exit 1 |
| 102 | + fi |
| 103 | + ``` |
| 104 | + - Run for each Python version: |
| 105 | + ```bash |
| 106 | + poetry run poe test_integration |
| 107 | + poetry run coverage report --fail-under=70 |
| 108 | + ``` |
| 109 | + - Stop container after all versions complete: `docker logs xrpld-service && docker stop xrpld-service` |
| 110 | + |
| 111 | +4. **Faucet tests**: |
| 112 | + ```bash |
| 113 | + poetry run poe test_faucet |
| 114 | + ``` |
| 115 | + |
| 116 | +Collect results from all parallel runs. All Python versions must pass. |
| 117 | + |
| 118 | +### Handling failures |
| 119 | + |
| 120 | +If any step fails, **attempt to fix the breaking change with code modifications before rolling back**. Common patterns: |
| 121 | + |
| 122 | +- **Type annotation changes**: newer versions of type stubs or mypy may require updated annotations. Fix the annotations. |
| 123 | +- **Deprecated API removals**: if an upgraded dependency removes a previously deprecated function, update calls to use the replacement API. |
| 124 | +- **Import path changes**: some packages reorganize their module structure on major bumps. Update import statements. |
| 125 | +- **Test compatibility**: if a test utility changes behavior (e.g., aiounittest, coverage), update test configuration or code accordingly. |
| 126 | + |
| 127 | +Only roll back and mark as Skipped if: |
| 128 | + |
| 129 | +- The fix requires a large-scale migration across the codebase |
| 130 | +- The upgrade is blocked by an external dependency constraint you cannot update |
| 131 | + |
| 132 | +If a failure is traced to a specific dependency upgrade, revert that upgrade in `pyproject.toml`, re-run `poetry lock && poetry install`, mark it as Skipped, and re-run validation until green. |
| 133 | + |
| 134 | +## Step 4: Generate Outputs |
| 135 | + |
| 136 | +After all upgrades are applied and validation passes, generate the following outputs: |
| 137 | + |
| 138 | +### 4a. Code changes note |
| 139 | + |
| 140 | +Write `.claude/skills/batch-deps-upgrade/code-changes.md` documenting every non-`pyproject.toml` source code change, explaining what broke, why, and the minimal fix applied. |
| 141 | + |
| 142 | +### 4b. PR description |
| 143 | + |
| 144 | +Write `.claude/skills/batch-deps-upgrade/pr-description.md` following the repo's PR template (`.github/pull_request_template.md`): |
| 145 | +
|
| 146 | +- For "High Level Overview of Change", summarize the batch upgrade. |
| 147 | +- For "Context of Change", explain that this batches Dependabot PRs to reduce merge noise. |
| 148 | +- For "Type of Change", determine dynamically: |
| 149 | + - Check "Breaking change" ONLY if any upgrade visibly changes the library's public API (e.g., error messages, return types, removed functions). This aligns with whether a `CHANGELOG.md` entry was added in Step 2.7. |
| 150 | + - Otherwise, do not check any Type of Change — dependency upgrades are maintenance and don't fit "Refactor" (which means restructuring code without behavior change). Note in the PR body that the upgrade is maintenance. |
| 151 | +- For "Did you update CHANGELOG.md?", check "Yes" if an entry was added, otherwise check "No, this change does not impact library users". |
| 152 | +- Include a "Superseded Dependabot PRs" section with a table: PR (linked), Package, From, To, Status, MajorVersionUpgrade |
| 153 | + - Status values: Upgraded, No-op (reason), Skipped (dependency conflict / CI failure: error) |
| 154 | + - MajorVersionUpgrade: `No` if the major version number did not change. Otherwise `Yes` plus a link for each major version crossed. For example, 1.x → 3.x yields `Yes ([v2](url), [v3](url))`. Each link should point to the package's release notes or changelog for that major version. Verify each link returns HTTP 200 and has meaningful content (e.g., `curl -sL -o /dev/null -w "%{http_code}" <url>`); if a package doesn't publish per-version GitHub releases, fall back to the CHANGELOG file or the closest valid release tag. |
| 155 | +- For every **major version upgrade**, add a "Major version upgrade notes" section below the table. For each major-version package, include: |
| 156 | + - A link to the release notes |
| 157 | + - A brief summary of key changes (breaking changes, deprecations, new features) |
| 158 | + - An explanation of why no code changes were required, OR a summary of the code changes that were made. This helps reviewers understand the impact without having to read the full release notes themselves. |
| 159 | +- Closing instructions with two paragraphs: |
| 160 | + 1. "After merging, close the following superseded PRs (Skipped ones remain open for future handling): #X, #Y, #Z" — list only Upgraded and No-op PRs. |
| 161 | + 2. "The following PRs were Skipped and should remain open: #A (package-a), #B (package-b), ..." — annotate each with the package name. These stay open so Dependabot keeps rebasing them. |
0 commit comments