nitrix
9a78ebd9b0
Encodes the workflow for creating PRs, monitoring CI status via Actions API (cross-referencing head SHA), and merging when green. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
95 lines
3.3 KiB
Markdown
95 lines
3.3 KiB
Markdown
---
|
|
name: merge-pr
|
|
description: Create a Gitea pull request, monitor CI pipeline status, and merge when green. Use this skill when the user asks to "create a PR", "merge the PR", "ship it", "make it ready to merge", or when you need to open a pull request and wait for CI before merging. Also use when asked to check CI/PR status on Gitea.
|
|
---
|
|
|
|
# Merge PR
|
|
|
|
Create a pull request on Gitea, monitor the CI pipeline via the Actions API, and merge once all jobs pass.
|
|
|
|
## Why this skill exists
|
|
|
|
The Gitea MCP pull request API does not return CI status directly. To know if a PR is ready to merge, you must cross-reference the PR's `head.sha` with the Actions runs API, find the matching run, and check job conclusions. This skill encodes that workflow so it doesn't have to be rediscovered.
|
|
|
|
## Prerequisites
|
|
|
|
The Gitea MCP tools must be available. The key tools are:
|
|
|
|
- `mcp__gitea__pull_request_write` (method: `create`, `merge`)
|
|
- `mcp__gitea__pull_request_read` (method: `get`)
|
|
- `mcp__gitea__actions_run_read` (methods: `list_runs`, `list_run_jobs`)
|
|
|
|
If these tools are not yet loaded, use ToolSearch to discover and load them before proceeding.
|
|
|
|
## Workflow
|
|
|
|
### 1. Create the PR
|
|
|
|
Use `mcp__gitea__pull_request_write` with method `create`. Include a clear title, body with summary and test plan, head branch, and base branch (usually `master`).
|
|
|
|
Save the returned `head.sha` — you need it to find the CI run.
|
|
|
|
### 2. Find the CI run for the PR
|
|
|
|
The Actions API has no direct "get CI status for PR" call. Instead:
|
|
|
|
```
|
|
mcp__gitea__actions_run_read(method: "list_runs", owner, repo, perPage: 5)
|
|
```
|
|
|
|
Find the run whose `head_sha` matches the PR's `head.sha`. This is the CI run triggered by the push that the PR points to. If the branch was force-pushed or new commits were added, always match against the latest `head.sha` from a fresh `get` on the PR.
|
|
|
|
### 3. Monitor job status
|
|
|
|
Once you have the run ID:
|
|
|
|
```
|
|
mcp__gitea__actions_run_read(method: "list_run_jobs", owner, repo, run_id: <id>)
|
|
```
|
|
|
|
This returns all jobs with their `status` (queued/in_progress/completed) and `conclusion` (success/failure/skipped/null).
|
|
|
|
Present a status table to the user:
|
|
|
|
| Job | Status |
|
|
|-----|--------|
|
|
| backend-test | success |
|
|
| frontend-test | in_progress |
|
|
| frontend-e2e | queued |
|
|
|
|
If jobs are still running, wait ~30 seconds and check again. Don't poll in a tight loop.
|
|
|
|
### 4. Handle failures
|
|
|
|
If any job has `conclusion: failure`:
|
|
- Use `mcp__gitea__actions_run_read` with method `get_job_log_preview` to fetch the failing job's log
|
|
- Report the failure to the user with relevant log output
|
|
- Do NOT attempt to merge
|
|
|
|
### 5. Merge when green
|
|
|
|
Once all jobs show `conclusion: success` (or `skipped` for conditional jobs like `build-and-publish`):
|
|
|
|
```
|
|
mcp__gitea__pull_request_write(
|
|
method: "merge",
|
|
owner, repo,
|
|
index: <pr_number>,
|
|
merge_style: "merge",
|
|
delete_branch: true
|
|
)
|
|
```
|
|
|
|
Ask the user for confirmation before merging. They may want to review the PR in the web UI first.
|
|
|
|
### 6. Post-merge cleanup
|
|
|
|
After a successful merge, suggest:
|
|
- `git checkout master && git pull origin master`
|
|
- `git branch -d <feature-branch>` (local cleanup)
|
|
- Tagging a release if appropriate (see `/release` skill)
|
|
|
|
## Abbreviated flow
|
|
|
|
When the user just wants a quick status check (e.g. "how's the PR?"), skip straight to steps 2-3: find the run by SHA, show the job status table.
|