Plan: Woodpecker SDK & MCP
Vision
Professional, stable MCP tooling for every platform service, built on swagger-generated SDKs with pytest integration tests and PyPI pipelines. Eliminate raw API calls from agent sessions.
Projects & Repos Touched
| Project/Repo | Platform | Role in this plan |
|---|---|---|
| woodpecker-sdk | Forgejo | Python SDK generated from swagger.json — 117 endpoints |
| woodpecker-mcp (new) | Forgejo | MCP server with workflow-level tools built on SDK (promoted to own plan) |
Context
We currently make raw HTTP calls to Woodpecker CI in every session that touches CI/CD. This wastes 500-1000 tokens per interaction, has no type safety, no error handling, and no retry logic. The SDK-first pattern (swagger.json → SDK → MCP) is proven across 5+ services (notion, gmail, gcal, linkedin, forgejo). Woodpecker is the most-used platform service without an SDK.
What's already done:
- [x] Swagger spec retrieved (117 endpoints, 22 tags)
- [x] forgejo-sdk pattern documented and understood
- [x] woodpecker-sdk repo created
- [x] SDK generated — 117 endpoints, 18 mixin files (PR #2 merged)
- [x] Integration tests — 70 tests with full response shape validation (PR #4 merged, 3 QA rounds)
- [x] Forgejo PyPI registry configured for publishing
- [x] Woodpecker CI pipeline for woodpecker-sdk (PR #6 merged, 3 QA rounds)
Previous Plan
None — originated from
todo-woodpecker-mcpDepends On
None
Decisions Made
| Decision | Rationale |
|---|---|
| Token auth (Bearer PAT), not basic auth | Woodpecker uses personal access tokens, not username/password |
| Mixin-per-tag pattern | Matches forgejo-sdk, keeps files manageable |
| SDK first, MCP second (separate plan) | SDK must be stable and tested before building MCP on top |
| Project: Claude Config | All SDK/MCP tooling lives under Claude Config, consistent with forgejo-sdk |
| Shared test schemas module | Deduplicated Secret/Registry/User schemas into tests/schemas.py across 6 test files |
| Dual httpx clients | Root-level endpoints (/version, /healthz) served outside /api — SDK uses _root_client |
| Publish to Forgejo package registry, not Harbor or public pypi.org | Harbor does NOT support PyPI registries (OCI artifacts only, confirmed via <a href="https://github.com/goharbor/harbor/discussions/19381">goharbor/harbor#19381</a>). Forgejo has a <a href="https://forgejo.org/docs/latest/user/packages/pypi/">built-in PyPI registry</a> — already enabled on our instance, zero new infrastructure, publish via twine, install via pip, all within Tailnet. 22 packages already leaked to public PyPI (can't delete, PEP 763). Going forward, all packages self-hosted on Forgejo. See <code>todo-forgejo-pypi</code> for migration of existing packages. |
| Ruff config in pyproject.toml | Keep all config colocated. No standalone ruff.toml. |
| Manual version bumping (for now) | Edit version in pyproject.toml by hand. Automate later (tag-based release) once the pipeline pattern is proven across multiple repos. |
| Integration tests run in CI | The SDK has 70 integration tests against live Woodpecker — run them in CI via secrets. Catches regressions against the real API. Worth the CI time. |
| Reuse Forgejo admin PAT for publishing | No need for a dedicated publishing token. Admin PAT already exists in secrets, works for twine upload. |
Phases
Phase 1 — Generate SDK from swagger.json ✅ COMPLETED
Slug:
Goal: Create woodpecker-sdk repo with full 117-endpoint coverage generated from swagger.json, following the forgejo-sdk mixin pattern.
Owner: Agent
Issue:
phase-2026-02-28-1-generate-sdkGoal: Create woodpecker-sdk repo with full 117-endpoint coverage generated from swagger.json, following the forgejo-sdk mixin pattern.
Owner: Agent
Issue:
issue-woodpecker-sdk-initial (resolved), issue-woodpecker-sdk-integration-tests (resolved)Deliverables:
- PR #2 — Initial SDK: 117 endpoints, 18 mixin files, 33 smoke tests (merged)
- PR #4 — Comprehensive integration tests: 70 tests with response shape validation against swagger schemas, shared schemas module (merged, 3 QA rounds)
- Woodpecker PAT saved to
~/secrets/woodpecker/credentials.env
Phase 2 — Forgejo PyPI registry + Woodpecker CI pipeline ✅ COMPLETED
Slug:
Goal: Configure Forgejo's built-in PyPI registry for package publishing, then create a Woodpecker CI pipeline for woodpecker-sdk that lints, tests, builds, and publishes to Forgejo. This establishes the reusable pipeline pattern for all future SDK/MCP repos.
Owner: Agent
Issue:
phase-2026-02-28-2-pypi-pipelineGoal: Configure Forgejo's built-in PyPI registry for package publishing, then create a Woodpecker CI pipeline for woodpecker-sdk that lints, tests, builds, and publishes to Forgejo. This establishes the reusable pipeline pattern for all future SDK/MCP repos.
Owner: Agent
Issue:
issue-woodpecker-sdk-pypi-pipeline (resolved)Deliverables:
- PR #6 — Woodpecker CI pipeline + Forgejo PyPI publishing (merged, 3 QA rounds)
.woodpecker.yml— 3-step pipeline: lint (ruff==0.15.2), test (pytest with live Woodpecker), publish (build + twine upload to Forgejo, main-only)pyproject.toml— ruff config added (py310, line-length 120, E/F/W/I rules)~/.pypircconfigured with Forgejo registry- Woodpecker secrets configured: repo-level (
woodpecker_url,woodpecker_token), global (forgejo_publish_user,forgejo_publish_token,forgejo_pypi_url) - v0.1.0 published to Forgejo PyPI and installable via
pip install - Ruff format fixes applied across 15 source/test files (mechanical, no logic changes)
Phase 3 — Woodpecker MCP ➔ Promoted to own plan
Slug:
Goal: MCP server with curated workflow-level tools built on SDK.
Promoted to:
Depends on: Phase 2 ✅ (SDK is now on Forgejo PyPI)
phase-2026-02-28-3-mcpGoal: MCP server with curated workflow-level tools built on SDK.
Promoted to:
plan-2026-02-28-woodpecker-mcpDepends on: Phase 2 ✅ (SDK is now on Forgejo PyPI)
Phase 3 was promoted to its own plan because the research and design work produced enough detail for a full plan: three-tier tool coverage model, 12 compound workflow tools designed, forgejo-mcp reference pattern studied, key architectural decisions made. See the new plan for full detail.
Key Files
| Phase | File | Repo | Change |
|---|---|---|---|
| 1 | swagger.json | woodpecker-sdk | Source spec |
| 1 | src/woodpecker_sdk/client.py | woodpecker-sdk | BaseClient + WoodpeckerClient (dual httpx clients) |
| 1 | src/woodpecker_sdk/*.py | woodpecker-sdk | 18 mixin files |
| 1 | tests/schemas.py | woodpecker-sdk | Shared schema constants (Secret, Registry, User) |
| 1 | tests/test_*.py | woodpecker-sdk | 18 test files, 70 tests with response shape validation |
| 1 | pyproject.toml | woodpecker-sdk | Package config |
| 2 | .woodpecker.yml | woodpecker-sdk | CI pipeline: lint, test, publish to Forgejo |
| 2 | pyproject.toml | woodpecker-sdk | Add ruff config section |
| 2 | ~/.pypirc | local machine | Forgejo PyPI registry config for twine |
| 2 | Woodpecker secrets | Woodpecker UI/API | Forgejo publish creds (global), Woodpecker PAT (repo-level for tests) |
Verification
- [x]
pytest tests/passes against live Woodpecker instance (65 pass, 5 skip) - [x] All 18 tag groups have corresponding mixin + test file
- [x]
pip install -e .works - [x] Can instantiate WoodpeckerClient and list repos
- [x] Forgejo package registry accepts
twine upload - [x]
pip install ldraney-woodpecker-sdkresolves from Forgejo - [x] Push to branch triggers lint + test in Woodpecker CI
- [x] Merge to main triggers build + publish to Forgejo
- [ ] Pipeline is reusable template for other SDK/MCP repos
Next Plan Seeds
- woodpecker-mcp — promoted to
plan-2026-02-28-woodpecker-mcp - forgejo-mcp audit — compare existing forgejo-sdk/mcp against this pattern
- Forgejo PyPI migration — move existing 22 public PyPI packages to Forgejo (
todo-forgejo-pypi) - Reusable .woodpecker.yml template — extract pipeline pattern for all Python repos
Related
plan-2026-02-28-woodpecker-mcp— child plan (Phase 3 promoted, dependency now satisfied)todo-woodpecker-mcp— originating TODOtodo-forgejo-mcp-audit— companion audittodo-forgejo-pypi— migrate all 22 public packages to Forgejotodo-ruff-standardization— ruff config across all Python repos- forgejo-sdk — reference implementation
service-onboarding-sop— container images still go to Harbor, Python packages go to Forgejo