Label PRs without bot comments as ready-for-review

[koppor]

Summary

🤖 PR Description

"Comment on PR" labels PRs without bot comments as status: no-bot-comments — and stops there, so a PR that is actually reviewable never gets status: ready-for-review from the bot. This changes the "no bot comments" branch: if the PR is not a draft, no reviewer requested changes (reviewDecision != CHANGES_REQUESTED), and it is not already at status: awaiting-second-review / status: to-be-merged, it now gets status: ready-for-review (replacing status: no-bot-comments). Otherwise the behavior is unchanged and status: no-bot-comments stays.

This is not a concurrency issue: the workflow simply never added ready-for-review. A review requesting changes that lands before CI finishes is caught by the reviewDecision check; one that lands after is still handled by "Adapt PR status labels (Move)".

Analogies: Like honey, this sweetens the reviewer queue by surfacing PRs that are actually ready. Like chocolate, it is a small piece with a noticeable effect. Like the moon, it only shows one face — ready-for-review or no-bot-comments, never both.

jabref-contrib-policy:4.2:reviewed​:ok

Steps to test

1. Open a PR from a fork, wait for "Source Code Tests" to finish without bot comments → PR gets status: ready-for-review.
2. Convert the PR to draft (or request changes as a reviewer), push again → PR gets status: no-bot-comments instead.

The jq filter was checked against live PR data: #16646 (to-be-merged) → not ready; #16620 (changes requested) → not ready; #16530 (draft) → not ready; #16667 → ready.

Related issues and pull requests

Closes _____ (no issue; maintainer request)

AI usage

Claude Code (model claude-fable-5), AIL4 — AI-generated from a maintainer's description, reviewed by the maintainer.

AI CHECKLIST.md walkthrough

1. Code self-review

Nullability and control flow

• [/] No == null / != null checks — JSpecify annotations used instead.
• [/] No Objects.requireNonNull(...).
• [/] New classes annotated with @NullMarked.
• [/] Optional consumed with ifPresent / map / orElseThrow.
• [/] StringUtil.isBlank(...) used.

Exceptions

• [/] No catch (Exception e).
• [/] No throw new RuntimeException(...) / IllegalStateException(...).
• [/] Logged exceptions passed as the last logger argument.

Style and idioms

• [/] New BibEntry objects built with withers.
• [/] Modern Java used.
• [/] Regexes use a precompiled Pattern.
• [/] Background work uses BackgroundTask.
• No commented-out code, no trivial comments, no AI-disclosure comments in source.
• [/] Markdown Javadoc uses Markdown syntax.

User-facing text

• [/] All user-facing text localized.
• [/] Sentence case; no trailing !; labels do not end with :.
• [/] Variance expressed with placeholders.

Security

• [/] User-controlled data HTML-escaped.

Tests

• [/] Behavior changes in org.jabref.model / org.jabref.logic have tests.
• [/] Tests assert object contents, plain JUnit asserts, no @DisplayName, @TempDir.
• [/] Fetcher tests hit live endpoints.

2. Verification commands

• [/] ./gradlew :jablib:check (workflow-only change).
• [/] ./gradlew checkstyleMain checkstyleTest checkstyleJmh.
• [/] ./gradlew modernizer.
• [/] ./gradlew --no-configuration-cache :rewriteDryRun.
• [/] ./gradlew javadoc.
• [/] npx markdownlint-cli2 (no Markdown changed).
• [/] intellij-format.

3. Documentation

• [/] CHANGELOG.md entry (not user-visible).
• Searched issues; none matching.
• [/] Requirement added to docs/requirements/.
• [/] Developer documentation under docs/ updated.

4. Pull request

• PR body built from .github/PULL_REQUEST_TEMPLATE.md, every section filled.
• All checklist items kept and marked.
• All HTML comments removed.
• PR created with gh pr create --body-file.
• [/] CHANGELOG.md TODO placeholder replaced.

Checklist

• I own the copyright of the code submitted and I license it under the MIT license
• If AI tools were used, I disclosed them in the "AI usage" section and reviewed, understood, and take full ownership of all AI-generated code
• [/] I manually tested my changes in running JabRef (always required)
• [/] I added JUnit tests for changes (if applicable)
• [/] I added screenshots in the PR description (if change is visible to the user)
• [/] I added a screenshot in the PR description showing a library with a single entry with me as author and as title the issue number
• [/] I described the change in CHANGELOG.md in a way that can be understood by the average user (if change is visible to the user)
• [/] I checked the user documentation for up to dateness and submitted a pull request to our user documentation repository

🤖 Generated with Claude Code

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Mark eligible PRs without bot comments ready for review

🐞 Bug fix ⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Promote eligible PRs without bot feedback to status: ready-for-review.
• Preserve status: no-bot-comments for blocked or advanced review states.

Diagram

graph TD
  Tests["Source Code Tests"] --> BotCheck{"Bot comments?"} -->|Yes| Changes["Changes required"]
  BotCheck -->|No| StateCheck{"PR ready?"} -->|Yes| Ready["Ready for review"]
  StateCheck -->|No| NoBot["No bot comments"]

Loading

High-Level Assessment

The inline GitHub CLI query is appropriate for this narrowly scoped workflow decision. It evaluates authoritative PR state immediately before relabeling, preserves later review stages, and avoids introducing a separate action or script for a small conditional.

Files changed (1) +15 / -3

Bug fix (1) +15 / -3

pr-comment.ymlPromote eligible comment-free PRs to ready for review +15/-3

Promote eligible comment-free PRs to ready for review

• Queries each comment-free PR's draft status, review decision, and progression labels before assigning its status. Eligible PRs replace 'status: no-bot-comments' with 'status: ready-for-review', while drafts, change-requested PRs, and later-stage PRs retain the existing label behavior.

.github/workflows/pr-comment.yml

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Not-ready PR retains ready label ✓ Resolved 📘 Rule violation ≡ Correctness

Description

The not-ready branch adds status: no-bot-comments without removing an existing `status:
ready-for-review`, so a previously ready PR converted to draft can retain both mutually exclusive
labels after CI reruns. Adding no-bot-comments triggers the label workflow, which sees the stale
ready label and runs gh pr ready, incorrectly converting the PR back out of draft.

Code

.github/workflows/pr-comment.yml[231]

+              gh issue --repo $REPO edit $PR_NUMBER --remove-label "status: changes-required,status: stale" --add-label "status: no-bot-comments"

Evidence

The new filter explicitly routes draft PRs to not-ready, but the changed fallback command removes
only status: changes-required,status: stale before adding status: no-bot-comments, allowing an
existing status: ready-for-review label to survive. Every newly added label triggers `On PR
labeled, whose follow-up workflow marks a draft PR ready whenever status: ready-for-review`
remains present; the normal changes-requested transition also confirms that the ready label is
expected to be removed from non-ready states, as required by compliance rule 1's established status
handling.

AGENTS.md: Preserve Architecture, Compatibility, and Focused Scope: AGENTS.md: Preserve Architecture, Compatibility, and Focused Scope: AGENTS.md: Preserve Architecture, Compatibility, and Focused Scope: AGENTS.md: Preserve Architecture, Compatibility, and Focused Scope
.github/workflows/pr-comment.yml[229-232]
.github/workflows/pr-comment.yml[219-231]
.github/workflows/on-pr-labeled.yml[27-40]
.github/workflows/on-pr-labeled-update-pr-status.yml[40-60]
.github/workflows/on-pr-changes-requested-move-labels.yml[34-38]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The `not-ready` branch leaves `status: ready-for-review` attached while adding `status: no-bot-comments`, producing contradictory status labels. Because adding a label triggers the PR-status workflow, a draft PR can then be incorrectly changed back to ready.
## Issue Context
A PR may first receive `status: ready-for-review`, then be converted to draft or receive a changes-requested review before the next CI completion. Status labels must remain mutually exclusive, so include `status: ready-for-review` among the labels removed by the `not-ready` branch while preserving later-stage labels as intended.
## Fix Focus Areas
- .github/workflows/pr-comment.yml[229-232]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can start a comment with 'qodo' or '@qodo' to chat about any finding

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗