Trigger CI checks on manual review

[derekmisler]

Summary

This PR adds GitHub Checks API integration to all three CI workflows so that manually triggered reviews and PR description generation are surfaced as proper check runs on the PR's commit. Previously, these workflows ran silently without any visible check status on the PR; now they create a check run at the start and update it to success, failure, or cancelled upon completion.

Changes

• .github/workflows/pr-describe.yml: Added checks: write permission, a Create check run step at job start (named Generate PR Description), and an Update check run step (runs always()) to finalize the check status.
• .github/workflows/review-pr.yml: Same pattern — added checks: write, creates a PR Review check run using the resolved pr-number input or issue.number, and updates it on completion.
• .github/workflows/self-review-pr.yml: Same pattern as review-pr.yml — adds checks: write, creates and finalizes a PR Review check run tied to the PR's head_sha.

How to Test

• Open a PR and manually trigger one of the review workflows (e.g., via a comment or workflow_dispatch); a PR Review or Generate PR Description check should appear on the PR's Checks tab showing in_progress and then resolve to success or failure.
• Cancel a running workflow mid-flight and verify the check run resolves to cancelled rather than hanging as in_progress.
• Confirm the check is attached to the correct commit SHA (the PR head, not the base branch).

[derekmisler]

/describe

[docker-agent]

✅ PR description has been generated and updated!

[simonferquel]

/review

[simonferquel]

I do not see the check :/

[docker-agent]

Review Summary

Assessment: 🟡 NEEDS_ATTENTION

This PR adds GitHub Checks API integration to surface workflow progress as check runs on PRs. The implementation is sound overall, but there are 4 potential issues related to error handling that should be addressed:

• 1 edge case where cancelled/timed-out workflows may leave orphaned in_progress checks
• 3 instances of missing error handling in checks.update() API calls that could leave checks in inconsistent states

All findings are medium severity and likely to occur under certain conditions (workflow cancellations, API failures, rate limiting).

Recommendations

1. Wrap API calls in try-catch blocks to provide proper error logging and recovery
2. Consider adding a cleanup mechanism for orphaned checks (e.g., a separate workflow that queries and closes stale in_progress checks)
3. Add error logging when check creation/update fails to aid debugging

The core functionality is well-designed with good safeguards (continue-on-error, if: always()), but the error paths need better handling.

[docker-agent]

Orphaned in_progress check run if workflow is cancelled or times out

While the if: always() condition on the update step ensures it runs on normal job completion, it won't execute if the workflow is cancelled at the job level or hits a hard timeout before reaching the update step. This could leave an orphaned check permanently spinning in in_progress status on the PR.

Recommendation: Consider adding a separate cleanup workflow that runs periodically to find and close stale in_progress check runs, or use GitHub's auto-timeout feature for checks (though this requires additional configuration).

[docker-agent]

Missing error handling for checks.update API call

The github.rest.checks.update() call is not wrapped in try-catch. If the API fails (rate limiting, network issues, invalid check_run_id), the step fails silently and may leave the check in an inconsistent state.

Recommendation: Wrap the API call in try-catch:

try {
  await github.rest.checks.update({
    owner: context.repo.owner,
    repo: context.repo.repo,
    check_run_id: parseInt(process.env.CHECK_ID, 10),
    status: 'completed',
    conclusion: conclusion,
    completed_at: new Date().toISOString()
  });
} catch (error) {
  core.warning(`Failed to update check run: ${error.message}`);
}

[docker-agent]

Missing error handling for checks.update API call

The github.rest.checks.update() call is not wrapped in try-catch. API failures will fail the step silently and may leave checks in inconsistent states.

Recommendation: Add try-catch error handling with logging (same pattern as pr-describe.yml suggestion).

[docker-agent]

Missing error handling for checks.update API call

The github.rest.checks.update() call lacks try-catch error handling. API failures could leave checks in an inconsistent state without proper logging.

Recommendation: Add try-catch error handling with logging (same pattern as pr-describe.yml suggestion).