oh-my-pr 2.5.0 → 2.7.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +15 -10
- package/dist/index.cjs +138 -75
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -1,6 +1,7 @@
|
|
|
1
|
-
#
|
|
1
|
+
# Oh-my-PR
|
|
2
|
+
**This project is going to save you tons of time by automating the whole PR process.**
|
|
2
3
|
|
|
3
|
-
**Local-first GitHub PR babysitter for Codex and Claude
|
|
4
|
+
**Local-first GitHub PR babysitter for Codex and Claude**
|
|
4
5
|
|
|
5
6
|
<p align="center">
|
|
6
7
|
<img width="409" height="409" alt="Code Factory logo" src="https://github.com/user-attachments/assets/ca339a71-40d9-4619-900f-55825f30a57f" />
|
|
@@ -12,9 +13,7 @@
|
|
|
12
13
|
[](https://nodejs.org/)
|
|
13
14
|
[](https://www.typescriptlang.org/)
|
|
14
15
|
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
No hosted service. No agent edits inside your working copy. Your PR automation stays on your machine.
|
|
16
|
+
Oh-my-pr babysits your PRs from your local machine, reads all PR comments and CI/CD logs, and gets your PR ready for merge to main. It uses your local Claude Code or Codex to address any issues identified in the PR or CI/CD pipeline and to ensure that any documentation is up to date. You can push a PR, walk away, and come back to a clean PR ready to be merged.
|
|
18
17
|
|
|
19
18
|
<img width="1365" height="686" alt="Code Factory dashboard" src="https://github.com/user-attachments/assets/66dfa082-c732-4989-8b05-f19aa550acb5" />
|
|
20
19
|
|
|
@@ -24,10 +23,11 @@ No hosted service. No agent edits inside your working copy. Your PR automation s
|
|
|
24
23
|
- Auto-register open PRs, archive closed or merged PRs, and keep syncing review activity.
|
|
25
24
|
- Pause background automation for an individual tracked PR while keeping manual runs available.
|
|
26
25
|
- Store PR state, background jobs, questions, release runs, logs, and social changelogs in SQLite with mirrored log files.
|
|
27
|
-
- Queue repo sync, babysit/apply runs, PR questions, release processing, and social changelog generation in a durable SQLite-backed dispatcher that survives restarts.
|
|
26
|
+
- Queue repo sync, babysit/apply runs, PR questions, release processing, deployment healing, and social changelog generation in a durable SQLite-backed dispatcher that survives restarts.
|
|
28
27
|
- Triage feedback into `accept`, `reject`, or `flag`, with manual overrides and retry for failed or warned items.
|
|
29
28
|
- Run `codex` or `claude` in isolated worktrees under `~/.oh-my-pr`, then push verified fixes back to the PR branch.
|
|
30
|
-
- Evaluate review comments and failing CI statuses, post GitHub follow-ups, resolve review threads, and
|
|
29
|
+
- Evaluate review comments and failing CI statuses, post GitHub follow-ups, resolve review threads, and heal CI failures through persisted CI healing sessions per PR head.
|
|
30
|
+
- Monitor merged Vercel or Railway deployments, capture deployment logs on failure, and open follow-up `deploy-fix/*` PRs when deployment healing is enabled.
|
|
31
31
|
- Detect merge conflicts and optionally let the agent resolve them automatically.
|
|
32
32
|
- Ask natural-language questions about any tracked PR from the dashboard or via MCP.
|
|
33
33
|
- Configure trusted reviewers, ignored bots, polling, batching, run limits, and CI-healing retry budgets from settings.
|
|
@@ -37,20 +37,24 @@ No hosted service. No agent edits inside your working copy. Your PR automation s
|
|
|
37
37
|
|
|
38
38
|
## How It Works
|
|
39
39
|
|
|
40
|
-
<img width="969" height="572" alt="Code Factory workflow" src="https://github.com/user-attachments/assets/b9dbd102-ae2e-4837-a862-a0282bdfa0b8" />
|
|
41
|
-
|
|
42
40
|
1. Add a repository to the watch list or register a PR directly by URL.
|
|
43
41
|
2. The watcher enqueues a durable repo-sync job in SQLite.
|
|
44
42
|
3. That sync job polls GitHub, auto-registers open PRs, syncs reviews and comments, archives PRs that closed upstream, records failing CI on the current head SHA, and queues babysitter runs for tracked PRs whose background watch is enabled.
|
|
45
43
|
4. Manual apply/babysit requests, PR questions, release processing, and social changelog generation go through the same durable queue before work executes in an app-owned repo cache and isolated git worktree under `~/.oh-my-pr`.
|
|
46
44
|
5. The agent applies fixes, verifies the result, pushes to the PR branch, updates GitHub threads, and writes logs for the full run.
|
|
47
45
|
|
|
48
|
-
Repo sync, babysit/apply, PR Q&A, release processing, and social changelog generation all run through durable background jobs stored in `state.sqlite`. On startup the dispatcher reclaims expired job leases, and interrupted babysitter runs are resumed from stored run context when possible.
|
|
46
|
+
Repo sync, babysit/apply, PR Q&A, release processing, deployment healing, and social changelog generation all run through durable background jobs stored in `state.sqlite`. On startup the dispatcher reclaims expired job leases, and interrupted babysitter runs are resumed from stored run context when possible.
|
|
49
47
|
|
|
50
48
|
## CI Healing
|
|
51
49
|
|
|
52
50
|
When `Automatic CI healing` is enabled, Code Factory creates a healing session for each failing PR head SHA, classifies failures as safe to fix in-branch or blocked external, and runs bounded repair attempts in isolated worktrees. The dashboard surfaces the current session state and retry budget, and the local API exposes `GET /api/healing-sessions` plus `GET /api/healing-sessions/:id` for operator visibility.
|
|
53
51
|
|
|
52
|
+
## Deployment Healing
|
|
53
|
+
|
|
54
|
+
When deployment healing is enabled through `PATCH /api/config`, Code Factory inspects merged PRs for supported deployment markers, waits for the post-merge deployment to appear, and polls the matching platform CLI for success or failure. On failure, it captures deployment logs, runs the configured agent from the merge commit in the app-owned repo cache, pushes a `deploy-fix/<platform>-<timestamp>` branch, and opens a follow-up PR against the merged base branch.
|
|
55
|
+
|
|
56
|
+
Deployment healing currently supports Vercel and Railway repositories detected from common repo-local config files. It requires the matching CLI in `PATH` and authenticated on the same machine running Code Factory. Session history is exposed through `GET /api/deployment-healing-sessions`, `GET /api/deployment-healing-sessions/:id`, and the matching MCP read tools.
|
|
57
|
+
|
|
54
58
|
## Quick Start
|
|
55
59
|
|
|
56
60
|
```bash
|
|
@@ -66,6 +70,7 @@ That's it. The dashboard opens in your browser at `http://localhost:5001`.
|
|
|
66
70
|
- **git**
|
|
67
71
|
- GitHub auth via `gh auth login`, `GITHUB_TOKEN`, app config, or a saved dashboard token
|
|
68
72
|
- Either the `codex` CLI or `claude` CLI installed and authenticated locally
|
|
73
|
+
- Optional for deployment healing: the `vercel` CLI and/or `railway` CLI installed and authenticated for repositories you want to auto-heal after merge
|
|
69
74
|
|
|
70
75
|
### CLI Usage
|
|
71
76
|
|