| … | … | @@ -0,0 +1,144 @@ |
| 1 | # CI Integration |
| 2 | |
| 3 | How to gate deploys on doc-code drift using codetree's `--check` mode. |
| 4 | |
| 5 | ## The idea |
| 6 | |
| 7 | `codetree docs . --check` scans a project, validates its specs against |
| 8 | real code, and exits `1` if drift exceeds configured thresholds. Drop |
| 9 | it into any CI pipeline that supports "fail the deploy on non-zero exit" |
| 10 | and your docs can never silently diverge from the code. |
| 11 | |
| 12 | Thresholds live in `.codetree.json` at the project root: |
| 13 | |
| 14 | ```json |
| 15 | { |
| 16 | "thresholds": { |
| 17 | "maxStalenessScore": 0.3, |
| 18 | "maxMissingRatio": 0.1, |
| 19 | "maxValidatorFailures": 0 |
| 20 | } |
| 21 | } |
| 22 | ``` |
| 23 | |
| 24 | CLI override: `--threshold 0.5` for a one-off relaxation. |
| 25 | |
| 26 | ## pear-git CI pipeline |
| 27 | |
| 28 | Add a step to your `.pear-git/ci.yaml`: |
| 29 | |
| 30 | ```yaml |
| 31 | steps: |
| 32 | - name: Install dependencies |
| 33 | run: npm install --production --ignore-scripts |
| 34 | timeout: 120 |
| 35 | |
| 36 | # Existing build / deploy steps... |
| 37 | # - name: Build |
| 38 | # run: npm run build |
| 39 | |
| 40 | # Gate on doc-code drift. |
| 41 | - name: Doc-code alignment (codetree) |
| 42 | # Soft gate — don't block deploys during initial rollout. Change |
| 43 | # `|| true` to nothing once your specs stabilize. |
| 44 | run: npx codetree docs . --check || true |
| 45 | timeout: 60 |
| 46 | ``` |
| 47 | |
| 48 | **Installation notes:** |
| 49 | |
| 50 | - `npx codetree` requires codetree to be installed locally |
| 51 | (`npm install codetree --save-dev`) OR globally in the CI runner's |
| 52 | `$PATH`. |
| 53 | - For pear-git's Bare runtime: a wrapper script in `~/.local/bin/` |
| 54 | pointing at the codetree checkout works (same pattern as |
| 55 | `git-remote-punch`). |
| 56 | |
| 57 | ## GitHub Actions |
| 58 | |
| 59 | ```yaml |
| 60 | - name: Doc-code alignment |
| 61 | run: | |
| 62 | npm install --no-save codetree |
| 63 | npx codetree docs . --check |
| 64 | ``` |
| 65 | |
| 66 | ## Jenkins / any shell-based CI |
| 67 | |
| 68 | ```bash |
| 69 | codetree docs . --check |
| 70 | # exit 1 fails the build |
| 71 | ``` |
| 72 | |
| 73 | ## Bootstrap pattern — soft gate first, hard gate later |
| 74 | |
| 75 | On initial rollout, **do not** fail the build immediately. Your specs |
| 76 | probably drifted over months/years of changes. The first run will |
| 77 | surface every drift. Sequence: |
| 78 | |
| 79 | 1. Add the step with `|| true` — collect reports, don't block deploys |
| 80 | 2. Run `codetree docs . --suggest` locally, review MANUAL REVIEW blocks |
| 81 | 3. Run `codetree docs . --apply` to land high-confidence fixes |
| 82 | 4. Commit + repeat until the check passes cleanly |
| 83 | 5. Remove `|| true` — now the gate is active. From this point, any |
| 84 | PR that drifts docs past threshold fails CI |
| 85 | |
| 86 | ## Per-PR visibility (future work) |
| 87 | |
| 88 | Planned (Phase 0f follow-up — not yet shipped): |
| 89 | |
| 90 | - Pre-receive hook on pear-git server-side that runs codetree against |
| 91 | the pushed commit, posts report as a deploy annotation |
| 92 | - "Docs drift" badge on the repo page in pear-git web UI |
| 93 | - Per-commit drift history, linkable from the graph view |
| 94 | |
| 95 | These require pear-git server integration beyond a ci.yaml step. |
| 96 | |
| 97 | ## What the gate catches |
| 98 | |
| 99 | | Threshold | What fails it | |
| 100 | |-----------|---------------| |
| 101 | | `maxStalenessScore` | Docs with too many broken references | |
| 102 | | `maxMissingRatio` | High ratio of missing-to-total refs in any doc | |
| 103 | | `maxValidatorFailures` | Spec claims that don't match real code | |
| 104 | |
| 105 | The gate does NOT catch: |
| 106 | |
| 107 | - Narrative drift ("BUG-3" references to a bug that's now fixed) — |
| 108 | these are low-confidence items surfaced by `--suggest`, not |
| 109 | automatically gated |
| 110 | - Undocumented exports/methods — these are `warn` in the validator |
| 111 | and don't count toward `maxValidatorFailures` (by design — forcing |
| 112 | 100% doc coverage tends to produce churny, low-value specs) |
| 113 | |
| 114 | Those require periodic `--suggest` review runs by humans, not a hard |
| 115 | gate. |
| 116 | |
| 117 | ## Debugging a failing gate |
| 118 | |
| 119 | ```bash |
| 120 | # See the full cruft report |
| 121 | codetree docs . --pretty |
| 122 | |
| 123 | # See what --check is complaining about |
| 124 | codetree docs . --check |
| 125 | |
| 126 | # See proposed fixes |
| 127 | codetree docs . --suggest |
| 128 | |
| 129 | # Apply mechanical fixes in bulk (LOC, deprecation markers) |
| 130 | codetree docs . --apply |
| 131 | |
| 132 | # Raise the threshold temporarily to unblock a deploy |
| 133 | codetree docs . --check --threshold 0.5 |
| 134 | ``` |
| 135 | |
| 136 | ## Philosophy |
| 137 | |
| 138 | `--check` is intentionally the last line of defense. The primary flow |
| 139 | is: operator runs `--suggest` / `--apply` during development, drift |
| 140 | never accumulates to CI-failure level. The gate catches the cases |
| 141 | where that hygiene fails. |
| 142 | |
| 143 | Don't use the gate as a substitute for regular suggest/apply passes — |
| 144 | use it as a safety net. |