Disable annotations from GitHub actions when reviewing a PR

[danielb987]

🏷️ Discussion Type

Product Feedback

Body

The annotations from GitHub actions in the source code is a real pain when reviewing a PR. It makes the Java code really difficult to read and is completely useless to me. The review process has become much much harder with these annotations. It's a pain.

Check warning on line R2665
setNameInBlocks(java.lang.String) in jmri.Section has been deprecated and marked for removal
Static Analysis Java25 / build

This image is from https://github.com/JMRI/JMRI/pull/15758/changes,
the file java/src/jmri/implementation/DefaultSection.java.

We have a GitHub action Static Analysis Java25 which gives these warnings.
But I don't want these annotations when reviewing a PR.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[100rootrain]

Those annotations aren't produced by the Static Analysis step itself. They come from actions/setup-java, which registers problem matchers (java, javac, maven-javac). The matchers turn every compiler [WARNING] File.java:[line,col] ... line in the log into an annotation on the diff. Your static-analysis-25.yml uses setup-java@v5, so every javac deprecation warning shows up inline.

You can turn that off in the workflow and keep the warnings in the log.

Option 1: upgrade to setup-java@v6, which added an input for this:

- name: Set up JDK 25
  uses: actions/setup-java@v6
  with:
    distribution: 'zulu'
    java-version: 25
    problem-matcher: false

Option 2: stay on v5 and unregister the matchers right after setup:

- name: Set up JDK 25
  uses: actions/setup-java@v5
  with:
    distribution: 'zulu'
    java-version: 25
- name: Disable compiler-warning annotations
  run: |
    echo "::remove-matcher owner=maven-javac::"
    echo "::remove-matcher owner=javac::"

Option 2 keeps the java matcher, so uncaught exceptions are still annotated. Only the compiler warnings go away. If static-analysis.yml and the other Java workflows also use setup-java, they'll need the same change.

The warnings are still in the job log, and the job still fails if the build fails, so you don't lose the static-analysis signal. It just stops being painted over the diff.

References

• setup-java docs, Java problem matcher (compiler annotations) and Disabling the problem matcher: https://github.com/actions/setup-java/blob/main/docs/advanced-usage.md#java-problem-matcher-compiler-annotations
• The matcher definitions (java, javac, maven-javac): https://github.com/actions/setup-java/blob/main/.github/java.json
• problem-matcher input, added in Add an option to disable Java problem matchers actions/setup-java#1133 (first released in v6.0.0, not in v5): https://github.com/actions/setup-java/blob/main/action.yml#L140
• ::remove-matcher owner=...:: command: https://github.com/actions/toolkit/blob/main/docs/commands.md#problem-matchers
• JMRI's workflow using setup-java@v5: https://github.com/JMRI/JMRI/blob/master/.github/workflows/static-analysis-25.yml

[RanaKhan77]

the deprecation warnings from actions/setup-java show up as inline annotations in the PR diff, which makes reviewing the actual code changes a pain.

The root cause is that actions/setup-java registers Java problem matchers (compiler diagnostics), as documented in the action's README. Once those matchers are active, any compiler output gets converted into annotations.

The cleanest fix is to disable matcher registration at the source:

- uses: actions/setup-java@v4
  with:
    problem-matcher: false

If you can't change the action input, you can remove the matcher mid-workflow:

- run: echo "::remove-matcher owner=java::"

One thing to keep in mind: without matchers, the log lines still appear in the raw workflow log — they just won't render as inline annotations in the diff. So you can still find the warnings if you need them, but the PR view stays clean.

The only link I can safely point you to is https://github.com/actions/setup-java, where the problem-matcher input is documented. Hope that unblocks you.

[danielb987]

Thank you!

It solved the problem. But it shouldn't have been enabled in the first place so I have added a bug report about it, actions/setup-java#1322.

And while it solves the problem for new PRs, it doesn't solve the problem for existing PRs. So I still have the problem for https://github.com/JMRI/JMRI/pull/15758/changes.