[hatayama]

Summary

• A dispatcher release no longer reports a false failure while the Unity package release waits behind other components' release checks.

User Impact

• Before: the release-please run checks release pull requests one at a time, newest first, so the package release pull request waited behind the project runner's checks (about 20–25 minutes). The dispatcher release's post-publish job waits 45 minutes for the package pull request's checks, timed out, and filed a release-failure comment, even though the release-please run merged the package release a few minutes later.
• After: the package release pull request's checks always run first, so post-publish waits for one check run and merges it itself.

Changes

• orderReleasePRsForChecks moves the unity-package release pull request to the front before the checks loop; every other pull request keeps its listed order.
• Tests: package-first dispatch, failing package checks still let the next pull request be marked ready, the ordering function (including the combined branch and a listing without a package pull request), and the failure summary now listing the package pull request first.
• docs/dispatcher-pin-release-order.md: one sentence on why the package pull request goes first.

Verification

• gofmt -l, go vet ./..., go test ./..., golangci-lint run ./..., golangci-lint fmt --diff ./... in cli/release-automation.
• Mutations: dropping the reorder call fails the package-first dispatch test and the failure-summary test; stopping the loop after the first failure fails the failing-package test.

[coderabbitai]

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: 6ed366ea-c60a-41f9-8e2d-4052f14d06eb

📥 Commits

Reviewing files that changed from the base of the PR and between c82f8be and b7b40a8.

📒 Files selected for processing: 5

• cli/release-automation/internal/automation/release_pr_checks.go
• cli/release-automation/internal/automation/release_pr_checks_test.go
• cli/release-automation/internal/automation/release_pr_lookup.go
• cli/release-automation/internal/automation/release_pr_lookup_test.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; 2 remain after this review.

📝 Walkthrough

Release automation now checks the Unity package PR first and preserves the listed order of other release PRs. Tests cover dispatch order and behavior when Unity package checks fail. Documentation records the ordering and workflow requirements.

Changes: Release Check Ordering

Layer / File(s)	Summary
Stable package-first ordering cli/release-automation/internal/automation/release_pr_lookup.go, cli/release-automation/internal/automation/release_pr_lookup_test.go	A stable ordering helper places the Unity package PR first and preserves the order of other PRs. Tests cover multiple PR listing scenarios.
Apply ordering to release checks cli/release-automation/internal/automation/release_pr_checks.go, cli/release-automation/internal/automation/release_pr_checks_test.go, docs/dispatcher-pin-release-order.md	Release checks use the ordering helper. Tests verify that dispatcher checks still run and its PR is marked ready when Unity package checks fail. Documentation records the package-first order and workflow requirements.

Priority: ⬇️ Low

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Merge Risk: ⚪ Minimal · up to b7b40

Unity package release checks are prioritized as intended. No issue requiring a fix before merge was identified.

Pre-merge checks: 5

Check name	Status	Explanation
Title check		The title clearly describes the primary fix: prioritizing the package release checks to prevent a false dispatcher release failure.
Description check		The description directly explains the release-check ordering change, its user impact, tests, documentation update, and verification steps.
Docstring Coverage		Docstring coverage is 90.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 10 functions across 4 files. (1 skipped: 1 …
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Full details: Docstring Coverage

Explanation

Docstring coverage is 90.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 10 functions across 4 files. (1 skipped: 1 unsupported.)

✨ Finishing Touches

📝 Generate docstrings

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autofix · 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.}