iTranslated by AI
Fully Automated Development Pipeline: From Issue Labeling to Merging
Introduction
Are your issues piling up in your personal projects? While you can automate implementation, the process of review → fixing feedback → merge often remains manual, becoming a bottleneck.
In this article, I will introduce a pipeline that turns into a fully automated cycle from implementation to merge simply by labeling an issue. The system works by having Claude Code write the code, GitHub Copilot review it, and then merging it automatically if there are no issues.
This setup utilizes GitHub Actions, Claude Code (GitHub Actions version), and the code review capabilities of GitHub Copilot.
Overall Architecture
The system consists of three GitHub Actions workflows chained together by events.
The key point here is that PR creation and merging act as triggers for the next workflow. There is no explicit setting to link workflows directly; they are naturally chained by GitHub events.
Note that because GitHub's GITHUB_TOKEN does not trigger subsequent workflows by design, I use a Fine-grained PAT (a personal access token with scoped repository permissions) to ensure the chain continues.
All that a human needs to do is "write an issue" and "apply a label."
Detailed Workflow Breakdown
① claude.yml — Implementation, Testing, and PR Creation
This workflow triggers when you apply the auto-implement label to an issue.
Claude Code Action reads the issue title, body, and comments. If there is a specification, it follows it; otherwise, it decides how to proceed based on the issue content.
After implementation, it runs tests (pytest / ruff / mypy / markdownlint / shellcheck) and creates a PR targeting the develop branch.
② copilot-auto-fix.yml — Review Detection, Correction, and Merge
This triggers automatically when a PR with the auto/ branch prefix is created. It does not run for manually created PRs.
Copilot Review Detection
Once a PR is created, GitHub Copilot automatically starts a code review. The workflow triggers upon PR creation and waits for the review to complete via polling.
Detection is performed by polling the REST API every 30 seconds, with a 10-minute timeout.
# Copilot review detection logic (simplified)
while [ "$elapsed" -lt "$timeout" ]; do
reviews=$(gh api "/repos/{owner}/{repo}/pulls/${pr}/reviews")
if echo "$reviews" | jq -e '.[] |
select(.user.login == "copilot-pull-request-reviewer[bot]")
| select(.state != "PENDING")' > /dev/null 2>&1; then
echo "Copilot review detected"
break
fi
sleep 30
done
Why use polling instead of an event trigger? I found that the pull_request_review event sometimes fails to generate a workflow run for reviews posted while Copilot's internal workflow is still running. It’s a bit unglamorous, but I determined that verifying directly via the API is more stable.
Automatic Correction → Merge
The workflow branches based on Copilot's review results:
- No feedback → Proceed directly to merge validation.
- Feedback exists → Claude Code Action applies fixes → Run tests → Commit & push → Resolve addressed threads via GraphQL API → Proceed to merge validation.
Design Decision: No Re-review Loop.
I have opted not to include a loop where Copilot reviews the corrected code again. Re-review loops carry the risk of "fixes creating new issues, leading to non-convergence." Instead, I manage quality by aggregating results in a post-merge tracking issue (see ③).
Merge Validation
Merge validation only passes if all 6 conditions are cleared.
| # | Condition | What it monitors |
|---|---|---|
| 1 | PR is OPEN | Is the PR still open via gh pr view? |
| 2 | Zero unresolved feedback | Are all review threads Resolved via GraphQL API? |
| 3 | Status checks passed | Have all CI (tests, linting, etc.) succeeded? |
| 4 | No conflicts | Is the PR auto-mergeable with the base branch? |
| 5 | No auto:failed label |
Is the stop label missing? |
| 6 | No forbidden changes | Are there changes to .env*, pyproject.toml, etc.? |
③ post-merge.yml — Merge Recording
This triggers automatically when a PR with the auto:merged label is merged.
Automatically merged PRs are recorded as comments in an aggregate issue labeled auto:review-batch. Since the PR number, title, and list of changed files are recorded, administrators can simply view this issue to confirm "what the auto-implementation did" in one place.
If there are no problems, the issue is closed, and a new one is automatically created for the next batch of auto-merges. By adopting an aggregate review approach rather than checking every single PR, management costs are kept low.
Safety Design
Because the entire process is automated, it is crucial to have mechanisms that reliably stop the pipeline when problems occur. I have implemented four layers of protection:
| # | Guard | Description |
|---|---|---|
| 1 | Unidirectional Flow | No re-review loop. Fixes are applied only once to prevent infinite loops. |
| 2 | Forbidden Patterns | Changes to .env* (secrets) or pyproject.toml (dependencies) are not auto-merged. |
| 3 | Concurrency Control | Prevents concurrent executions for the same PR. |
| 4 | 6-Point Pre-merge Check | Validation must pass all conditions before merging. |
If any guard is triggered, the auto:failed label is automatically applied. Since each workflow checks for this label before execution, the pipeline never proceeds to the next step when an issue is detected.
Design Decisions
Here is a summary of the branching points I considered during development:
| Decision | Reason |
|---|---|
| Polling with sleep for Copilot detection | Encountered cases where event triggers failed (see ②). |
| Abolishing the re-review loop | To avoid the risk of non-convergence (see ②). |
| Two-branch system (develop + main) | Uses develop as a sandbox for auto-merges, ensuring main stability. |
| Merging without manual pre-check | Waiting for human confirmation becomes a bottleneck. Errors stop automatically via auto:failed, and quality is verified in aggregate via the tracking issue (③). |
Operational Performance
Once the pipeline was set up, I tested it while traveling. I planned to verify it leisurely on a train trip around Lake Biwa, taking the Kosei Line from Yamashina through Tsuruga. All I had to do was apply labels to issues using my smartphone.
- The first PR was merged about 7 minutes after I started applying labels.
- 3 more were completed while I enjoyed the view of Lake Biwa from the train window.
- Copilot provided feedback for the first time mid-trip, but Claude Code addressed it automatically and the PR was merged successfully.
- By the time I arrived in Tsuruga, all remaining tasks were processed.
In about an hour and a half, I processed 12 items without waiting to finish the full circuit of the lake. 9 of these were completely auto-merged, while the remaining 3 were correctly halted due to forbidden pattern violations. The tasks were mostly routine, such as adding docstrings or reinforcing tests.
Implementation Notes
This setup is currently running in my personal development project.
- Suitable Tasks: Simple bug fixes, minor feature additions, and routine changes. It is not suitable for implementations requiring complex design decisions or tasks where you prefer to review details manually.
- Stronger PAT Permissions Required: Requires Read and Write access for Contents, Issues, Pull Requests, and Workflows. I recommend using a Fine-grained PAT to limit the scope to specific repositories.
- Private Repository Recommended: Due to the nature of triggering code generation via issues, there is a risk of generating unintended code through malicious issues in public repositories. However, GitHub now provides settings to restrict PR creation to collaborators, which helps mitigate risks even for public projects.
Conclusion
- Just apply a label to an issue, and the entire process from implementation to review, fix, and merge becomes fully automated.
- Three workflows work in tandem: Claude Code implements and fixes, while Copilot reviews.
- Four protection guards ensure the system stops reliably if problems occur.
- Abolishing the re-review loop ensures convergence through a unidirectional flow.
The experience of seeing issues get resolved automatically is genuinely satisfying. I find it practical to continue performing complex implementation manually while delegating routine tasks to this pipeline.
Discussion