fix: A green Unity package release pull request is merged even when GitHub lists its finished checks late

[hatayama]

Summary

• merge-package-release-pr gains --checks-grace-seconds. Under --no-wait, a pass that is waiting only on the head's check runs is re-read until the grace runs out; then the pull request is left draft as before.
• A stale pin still decides in one pass (the stamp takes far longer than any grace), so the push-triggered run does not hold a runner open for it.
• release-please.yml passes --checks-grace-seconds 120; docs/dispatcher-pin-release-order.md records why.

Why

The release-please path runs the merge with --no-wait right after the dispatch step has watched the release PR checks to completion. GitHub's per-workflow run listing (gh run list --workflow --branch) can lag that completion: today a build-and-test.yml run finished at 12:41:44, the merge step queried at 12:42:00 and found nothing finished for the head, and the same query returned the completed run by 12:42:39. Because every release-please run moves the release branch head, re-running it hits the same window again, so the 3.11.5 package release PR stayed draft.

Verification

• New tests: checks appearing within the grace merge; checks missing past the grace leave the PR draft with exit 0; a stale pin ignores the grace; a negative grace is rejected.
• scripts/check-go-cli.sh, scripts/test-release-please-config.sh, scripts/test-dispatcher-publish-workflow.sh pass locally.

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

🧰 Additional context used

📚 Code guidelines (2)

docs/dispatcher-pin-release-order.md — auto-discovered
AGENTS.md — auto-discovered

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Repository: hatayama/unity-cli-loop/.coderabbit.yaml
• Review profile: CHILL
• Plan: Advanced
• Run ID: 4d76e32f-8631-4f0a-ba2a-4e66f8a38e30

📥 Commits

Reviewing files that changed from the base of the PR and between 580dc2e and 953fccd.

📒 Files selected for processing (5)

• .github/workflows/release-please.yml
• cli/release-automation/internal/automation/package_release_pr_merge.go
• cli/release-automation/internal/automation/package_release_pr_merge_test.go
• cli/release-automation/internal/automation/package_release_pr_ready_merge.go
• docs/dispatcher-pin-release-order.md

Included review availability: This review used your included allowance. Your plan provides up to 4 included reviews per hour; 3 remain after this review.

---

📝 Walkthrough

Walkthrough

The package-release merge command now supports a configurable grace period for unfinished checks in no-wait mode. The release workflow sets the period to 120 seconds, and the release instructions describe the check re-read behavior.

Changes

Package Release PR Check Grace

Layer / File(s)	Summary
Outcome-aware checks grace cli/release-automation/internal/automation/package_release_pr_merge.go, cli/release-automation/internal/automation/package_release_pr_ready_merge.go, cli/release-automation/internal/automation/package_release_pr_merge_test.go	The command adds --checks-grace-seconds and distinguishes unfinished checks from other unsettled outcomes. In no-wait mode, it rechecks unfinished checks until the grace period ends. Tests cover checks appearing or remaining unfinished, stale pins, and negative values.
Release workflow configuration .github/workflows/release-please.yml, docs/dispatcher-pin-release-order.md	The release workflow passes a 120-second grace value. The release instructions describe re-reading checks for up to two minutes.

Priority: ➖ Normal

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Bug fix

Sequence Diagram(s)

sequenceDiagram
  participant ReleaseWorkflow
  participant MergeCommand as merge-package-release-pr
  participant GitHubPRChecks
  ReleaseWorkflow->>MergeCommand: invoke with 120-second grace
  MergeCommand->>GitHubPRChecks: list package PR and check status
  GitHubPRChecks-->>MergeCommand: return unfinished checks
  MergeCommand->>GitHubPRChecks: re-read checks during grace
  GitHubPRChecks-->>MergeCommand: return updated check status
  MergeCommand->>GitHubPRChecks: merge when checks pass

Loading

Merge Risk: ⚪ Minimal · up to 953fc

The release workflow can recheck unfinished package-release checks for up to two minutes. No actionable merge-blocking issue is identified; normal checks remain appropriate before merging.

Security Architecture Review

Security architecture risk: ⚪ Minimal · up to 953fc

The grace period changes when automation rechecks a release PR, not what it must verify before merging. Exact-head checks, dispatcher-pin validation and merge-time head matching remain enforced. No material security risk was found introduced or worsened by this change.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — The changed decision path remains scoped to the configured repository’s Unity package-release PR. Repository, base-branch, pending-release label and expected branch-name selection are unchanged. The grace option adds repeated reads, not access to additional repositories or greater merge authority.

Trust Boundaries and Controls

• observed — PR metadata and workflow results are not treated as sufficient merge authority by themselves. The pin is read at the discovered head SHA, every required workflow must have a completed successful run for that SHA, and the merge uses --match-head-commit. A head changed after verification therefore cannot be merged through this write using the stale verification.

Resilience and Maintainability Implications

• observed — Grace retries do not ready or merge a PR while checks remain unresolved. Failed checks and command errors terminate with failure; interrupted polling also fails. Existing concurrent ready/merge reconciliation remains unchanged, and merge failures are not converted into additional grace retries.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 75.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 12 functions across 3 files. (2 skipped: …	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly describes the delayed-check issue that the change addresses. It is longer than preferred, but it remains specific and relevant.
Description check	✅ Passed	The description explains the grace-period change, its rationale, and the reported verification. It is directly related to the changeset.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

Full details: Docstring Coverage

Explanation

Docstring coverage is 75.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 12 functions across 3 files. (2 skipped: 2 unsupported.)

• Fix all pre-merge checks with AI

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}