You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
bugfix-314-error-merging-release-branch-after-successful-deployment: Enhance documentation and implementation for deploy label and merge flow. Added new sections in README and index.mdx, and improved MergeRepository to wait for PR-specific check runs before merging. Updated tests for MergeRepository and DeployedActionUseCase to cover new behavior and ensure correctness in handling merges and check waits.
Copy file name to clipboardExpand all lines: README.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -23,6 +23,7 @@ Full documentation: **[docs.page/vypdev/copilot](https://docs.page/vypdev/copilo
23
23
|[OpenCode (AI)](https://docs.page/vypdev/copilot/opencode-integration)| Progress, Bugbot, think, AI PR description |
24
24
|[Testing OpenCode locally](https://docs.page/vypdev/copilot/testing-opencode-plan-locally)| Run check-progress, detect-potential-problems, recommend-steps via CLI |
|[Deploy label and merge flow](docs/single-actions/deploy-label-and-merge.mdx)| Deploy/deployed labels, post-deploy merges, waiting for checks per PR |
description: How the deploy and deployed labels work and how post-deploy merges and check runs are handled.
4
+
---
5
+
6
+
# Deploy label and merge flow
7
+
8
+
This page describes how the **deploy** label is used and what happens when you run the **deployed** single action after a successful deployment. It also explains how branch merges and check runs are handled so that both release→default and release→develop (or hotfix equivalents) complete correctly.
9
+
10
+
## The deploy label
11
+
12
+
-**`deploy`** — Applied to the issue when the release (or hotfix) is ready to be deployed. Your CI/CD or team adds this label when deployment has been triggered or is about to be.
13
+
-**`deployed`** — Set by Copilot when the **deployed** single action runs and the issue had the **deploy** label. It indicates "deployment is done and post-deploy steps have been run."
14
+
15
+
The **deployed** single action is intended to be run **after a successful deployment** (e.g. from a pipeline step or a manual trigger). It requires:
16
+
17
+
- An issue number (single action is run with `single-action-issue: <number>`).
18
+
- The issue must have the **deploy** label and must **not** already have the **deployed** label.
19
+
20
+
## What the deployed action does
21
+
22
+
1.**Label update**
23
+
Replaces the **deploy** label with **deployed** on the issue.
24
+
25
+
2.**Branch merges** (if a release or hotfix branch is configured):
26
+
-**Release:** merges the release branch into the default branch (e.g. `main`), then into the development branch (e.g. `develop`).
27
+
-**Hotfix:** merges the hotfix branch into the default branch, then merges the default branch into the development branch.
28
+
29
+
3.**Issue closure**
30
+
If **all** merge operations succeed, the issue is closed. If any merge fails, the issue is left open and the action reports that one or more merge operations failed.
31
+
32
+
Each merge is done via a **pull request**: create PR, wait for checks (see below), then merge the PR. If the PR workflow fails (e.g. checks fail or timeout), the code falls back to a **direct** Git merge when possible.
33
+
34
+
## Waiting for checks before merging
35
+
36
+
For each PR we create (e.g. release→main, release→develop), we wait until the PR is ready to merge before calling the merge API.
37
+
38
+
### Per-PR check runs
39
+
40
+
- GitHub's Checks API returns check runs **by ref** (branch), not by PR. The same branch can be the head of **multiple PRs** (e.g. release→main and release→develop).
41
+
- We **only consider check runs that belong to the current PR**, using the `pull_requests` array on each check run (filter by `pull_request.number === this PR`). We do **not** use check runs from another PR (e.g. the first merge) to decide that the second PR is ready.
42
+
- We wait until all check runs for **this** PR are completed and none have failed. Only then do we merge.
43
+
44
+
### When the PR has no check runs
45
+
46
+
- If there are **no** check runs on the ref, we use **commit status checks** (legacy) and merge when none are pending.
47
+
- If there **are** check runs on the ref but **none** for this PR (e.g. they are from another PR with the same head, or this base branch has no required checks), we wait a short number of polls (~30 seconds). If no check runs appear for this PR in that window, we assume this PR does not require check runs and **proceed to merge**. If the branch actually requires checks, GitHub will reject the merge and we fall back to the direct merge path (which may also fail under branch protection).
48
+
49
+
### Timeout
50
+
51
+
- A configurable **merge timeout** (input `merge-timeout`, default 600 seconds) limits how long we wait for checks **per merge**. If we hit the timeout, we throw and the code attempts a direct merge as fallback.
52
+
53
+
## Summary table
54
+
55
+
| Scenario | Behaviour |
56
+
|----------|-----------|
57
+
| PR has check runs for this PR | Wait until all are completed and none failed, then merge. |
58
+
| PR has no check runs on ref | Use status checks; if none pending, merge. |
59
+
| Check runs on ref but none for this PR | Wait a few polls (~30 s); if still none, proceed to merge (branch may have no required checks). |
60
+
| Timeout waiting for checks | Attempt direct merge. |
61
+
| PR merge fails, direct merge fails | Return failure; issue is not closed. |
-**Merge and checks:**`src/data/repository/merge_repository.ts` — PR creation, per-PR check filtering, status checks fallback, direct merge fallback.
67
+
-**Tests:**
68
+
-`src/usecase/actions/__tests__/deployed_action_use_case.test.ts` — deploy label validation, release/hotfix merge order, close on success, no close on merge failure.
69
+
-`src/data/repository/__tests__/merge_repository.test.ts` — check runs per PR, no check runs, timeout, direct merge fallback.
* Repository for merging branches (via PR or direct merge).
7
-
* Isolated to allow unit tests with mocked Octokit.
6
+
* Repository for merging branches: creates a PR, waits for that PR's check runs (or status checks),
7
+
* then merges the PR; on failure, falls back to a direct Git merge.
8
+
*
9
+
* Check runs are filtered by PR (pull_requests) so we only wait for the current PR's checks,
10
+
* not those of another PR sharing the same head (e.g. release→main vs release→develop).
11
+
* If the PR has no check runs after a short wait, we proceed to merge (branch may have no required checks).
12
+
*
13
+
* @see docs/single-actions/deploy-label-and-merge.mdx for the deploy flow and check-wait behaviour.
8
14
*/
9
15
exportclassMergeRepository{
10
16
@@ -61,10 +67,13 @@ This PR merges **${head}** into **${base}**.
61
67
});
62
68
63
69
constiteration=10;
70
+
/** Give workflows a short window to register check runs for this PR; after this, we allow merge with no check runs (e.g. branch has no required checks). */
71
+
constmaxWaitForPrChecksAttempts=3;
64
72
if(timeout>iteration){
65
73
// Wait for checks to complete - can use regular token for reading checks
0 commit comments