ci: update conflict predictor comment action

[thepastaclaw]

PR Body

Summary

• Update mshick/add-pr-comment from v2 to v3 in the
  predict-conflicts workflow.
• Keep the existing least-privilege workflow permissions unchanged.
• Align predict-conflicts with the already-updated merge-check workflow
  comment action.

Motivation

Several draft PRs are showing red predict_conflicts jobs where the conflict
check itself succeeds, but the sticky PR comment step fails with:

Resource not accessible by integration

The sibling merge-check workflow already uses mshick/add-pr-comment@v3 under
pull-requests: write, so this brings predict-conflicts onto the same action
version without broadening the token scope.

Validation

• git diff --check
• Pre-PR code review gate passed:
  Code review was run against upstream/develop and the feature branch.
  Result: no significant issues found; recommendation: ship.
• Inspected failing workflow logs for authored PRs showing failures in
  mshick/add-pr-comment@v2 with Resource not accessible by integration.

[github-actions]

✅ No Merge Conflicts Detected

This PR currently has no conflicts with other open PRs.

[thepastaclaw]

✅ Review complete (commit 5d0c7d1)

[thepastaclaw]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 1e9dfe34-73fd-40e9-a37c-b352c8ac7f47

📥 Commits

Reviewing files that changed from the base of the PR and between 5fd84aa and 0e78944.

📒 Files selected for processing (1)

• .github/workflows/predict-conflicts.yml

---

Walkthrough

The pull request updates the predict-conflicts GitHub Actions workflow to use version 3 of the mshick/add-pr-comment action in two locations: the "Post conflict comment" step (line 38) and the "Remove conflict comment if no conflicts" step (line 51). Both locations previously used @v2. The conditions, message identifiers, and message content remain unchanged.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately and concisely summarizes the main change: updating the GitHub Action version in the conflict predictor workflow.
Description check	✅ Passed	The description is well-related to the changeset, providing clear context about updating mshick/add-pr-comment from v2 to v3 and explaining the motivation and validation.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
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.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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 and usage tips.}

[thepastaclaw]

Code Review

Minimal CI workflow change: bumps mshick/add-pr-comment from v2 to v3 at two call sites in .github/workflows/predict-conflicts.yml, aligning with the sibling merge-check.yml workflow that already uses v3. The message-id/message inputs and pull-requests: write permission are unchanged and remain supported in v3. No correctness, security, or consensus concerns.

Reviewed commit: 0e78944

[thepastaclaw]

Code Review

CI-only change: bumps mshick/add-pr-comment to v3 and adds issues: write to the workflow's least-privilege permission set with an inline justification comment. The action bump is consistent with sibling merge-check.yml. The permission expansion is the only point worth a brief note — sibling workflow runs v3 with just pull-requests: write, but it does not use sticky message-id updates. No blocking issues.

Reviewed commit: 3c5105c

🟡 1 suggestion(s)

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `.github/workflows/predict-conflicts.yml`:
- [SUGGESTION] line 11: Inconsistent permission scope vs. sibling merge-check.yml
  This workflow now grants `issues: write` (was `issues: none`) with the rationale that `mshick/add-pr-comment` updates PR comments via the Issues API. However, `.github/workflows/merge-check.yml` uses the same `mshick/add-pr-comment@v3` with only `pull-requests: write` and posts PR comments successfully. In GitHub's permission model, PR comments are accessible via either `pull-requests: write` or `issues: write` since they share the `/issues/{n}/comments` endpoint, so `pull-requests: write` should normally be sufficient. The plausible difference here is the use of `message-id: conflict-prediction` for sticky comment updates, which may exercise a code path in v3 that the simple post-once usage in `merge-check.yml` does not. If a concrete v3 failure was observed without `issues: write`, a one-line note linking to the failing run (or to a v2→v3 migration note) in the comment would harden the justification. Otherwise, dropping `issues: write` to match the rest of the repo and the PR description's stated least-privilege intent would be cleaner. Not blocking — over-granting `issues: write` on a PR-only workflow is low-risk.

[thepastaclaw]

🟡 Suggestion: Inconsistent permission scope vs. sibling merge-check.yml

This workflow now grants issues: write (was issues: none) with the rationale that mshick/add-pr-comment updates PR comments via the Issues API. However, .github/workflows/merge-check.yml uses the same mshick/add-pr-comment@v3 with only pull-requests: write and posts PR comments successfully. In GitHub's permission model, PR comments are accessible via either pull-requests: write or issues: write since they share the /issues/{n}/comments endpoint, so pull-requests: write should normally be sufficient. The plausible difference here is the use of message-id: conflict-prediction for sticky comment updates, which may exercise a code path in v3 that the simple post-once usage in merge-check.yml does not. If a concrete v3 failure was observed without issues: write, a one-line note linking to the failing run (or to a v2→v3 migration note) in the comment would harden the justification. Otherwise, dropping issues: write to match the rest of the repo and the PR description's stated least-privilege intent would be cleaner. Not blocking — over-granting issues: write on a PR-only workflow is low-risk.

_{source: ['claude']}

🤖 Fix this with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `.github/workflows/predict-conflicts.yml`:
- [SUGGESTION] line 11: Inconsistent permission scope vs. sibling merge-check.yml
  This workflow now grants `issues: write` (was `issues: none`) with the rationale that `mshick/add-pr-comment` updates PR comments via the Issues API. However, `.github/workflows/merge-check.yml` uses the same `mshick/add-pr-comment@v3` with only `pull-requests: write` and posts PR comments successfully. In GitHub's permission model, PR comments are accessible via either `pull-requests: write` or `issues: write` since they share the `/issues/{n}/comments` endpoint, so `pull-requests: write` should normally be sufficient. The plausible difference here is the use of `message-id: conflict-prediction` for sticky comment updates, which may exercise a code path in v3 that the simple post-once usage in `merge-check.yml` does not. If a concrete v3 failure was observed without `issues: write`, a one-line note linking to the failing run (or to a v2→v3 migration note) in the comment would harden the justification. Otherwise, dropping `issues: write` to match the rest of the repo and the PR description's stated least-privilege intent would be cleaner. Not blocking — over-granting `issues: write` on a PR-only workflow is low-risk.

[thepastaclaw]

Code Review

CI-only change bumping mshick/add-pr-comment from v2 to v3 in .github/workflows/predict-conflicts.yml, adding issues: write (with inline justification for the v3 sticky-comment code path) and continue-on-error: true on both comment steps so a comment failure doesn't fail the job. No correctness, security, or consensus concerns. One low-signal nitpick about whether the new permission is actually required.

Reviewed commit: 5d0c7d1

💬 1 nitpick(s)

[thepastaclaw]

💬 Nitpick: issues: write may not be required; sibling workflow runs v3 with only pull-requests: write

The sibling .github/workflows/merge-check.yml uses mshick/add-pr-comment@v3 successfully with only pull-requests: write. The likely reason this workflow needs more is the message-id: conflict-prediction sticky-update path, which appears to exercise the Issues API in v3 — that matches the inline comment. If that was confirmed empirically (e.g., a failing run without issues: write), the justification is sufficient and this can be ignored. Otherwise, dropping it would match the rest of the repo's least-privilege posture. With continue-on-error: true now on both comment steps, this is purely cosmetic. Not blocking.

_{source: ['claude']}