Skip to content

ci: update conflict predictor comment action #7316

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
PastaPastaPasta merged 3 commits into from
May 12, 2026
+5 −3
Merged

ci: update conflict predictor comment action #7316

Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
0e78944
ci: update conflict predictor comment action
thepastaclaw May 9, 2026
3c5105c
ci: allow conflict predictor to update PR comments
thepastaclaw May 9, 2026
5d0c7d1
ci: tolerate conflict comment permission errors
thepastaclaw May 10, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions .github/workflows/predict-conflicts.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,11 +8,11 @@ on:
permissions:
contents: read
pull-requests: write
issues: write # mshick/add-pr-comment updates PR conversation comments via the Issues API
Copy link
Copy Markdown
Author

@thepastaclaw thepastaclaw May 10, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 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.

Copy link
Copy Markdown
Author

@thepastaclaw thepastaclaw May 10, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💬 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']

Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector Bot May 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Avoid granting Issues write to the whole job

Because this workflow runs on pull_request_target / pull_request_review, this line gives every third-party action in the job, including PastaPastaPasta/[email protected], a token that can write repository issues. GitHub's REST docs for creating/updating issue comments state that Pull requests write is accepted as an alternative to Issues write, and mshick/add-pr-comment@v3 documents only pull-requests: write for PR comments, so the existing permission should be sufficient without broadening the job-wide token scope.

Useful? React with 👍 / 👎.

# Enforce other not needed permissions are off
actions: none
checks: none
deployments: none
issues: none
packages: none
repository-projects: none
security-events: none
Expand All @@ -35,7 +35,7 @@ jobs:
continue-on-error: true
- name: Post conflict comment
if: steps.validate_conflicts.outputs.has_conflicts == 'true'
uses: mshick/add-pr-comment@v2
uses: mshick/add-pr-comment@v3
with:
message-id: conflict-prediction
message: |
Expand All @@ -48,7 +48,7 @@ jobs:
Please coordinate with the authors of these PRs to avoid merge conflicts.
- name: Remove conflict comment if no conflicts
if: steps.validate_conflicts.outputs.has_conflicts == 'false'
uses: mshick/add-pr-comment@v2
uses: mshick/add-pr-comment@v3
with:
message-id: conflict-prediction
message: |
Expand Down
Loading