Summary
The CLA Assistant workflow fails on every comment posted to a plain (non-PR) issue. .github/workflows/cla.yml triggers on issue_comment, which fires for comments on both issues and pull requests, and the job has no condition filtering out the former. The cla-assistant action then assumes a PR context and errors:
##[error]graphql call to get the committers details failed: GraphqlError: Could not resolve to a PullRequest with the number of 465.
Example failing runs, both triggered by ordinary comments on issue #465:
This does not affect CLA enforcement on actual PRs (those runs pass), but every issue comment by anyone produces a red-X run in the Actions tab and burns a runner minute.
Proposal
Add the if: gate from cla-assistant's own setup instructions to the cla job:
if: (github.event.comment.body == 'recheck' || github.event.comment.body == 'I have read the CLA Document and I hereby sign the CLA') || github.event_name == 'pull_request_target'
Comment-triggered runs then only fire for the two magic phrases (which only meaningfully occur on PRs), so plain issue chatter never reaches the action.
Acceptance criteria
- Commenting on a non-PR issue triggers no CLA Assistant run (or a skipped one).
- Signing via the magic phrase and
recheck on a PR still work.
- CLA enforcement on
pull_request_target events is unchanged.
Happy to pick this up as a one-line follow-up.
Summary
The CLA Assistant workflow fails on every comment posted to a plain (non-PR) issue.
.github/workflows/cla.ymltriggers onissue_comment, which fires for comments on both issues and pull requests, and the job has no condition filtering out the former. The cla-assistant action then assumes a PR context and errors:Example failing runs, both triggered by ordinary comments on issue #465:
This does not affect CLA enforcement on actual PRs (those runs pass), but every issue comment by anyone produces a red-X run in the Actions tab and burns a runner minute.
Proposal
Add the
if:gate from cla-assistant's own setup instructions to theclajob:Comment-triggered runs then only fire for the two magic phrases (which only meaningfully occur on PRs), so plain issue chatter never reaches the action.
Acceptance criteria
recheckon a PR still work.pull_request_targetevents is unchanged.Happy to pick this up as a one-line follow-up.