Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.12%. Comparing base (f2bafb2) to head (b786307).
Report is 1 commits behind head on master.

@@            Coverage Diff            @@
##             master    #1111   +/-   ##
=========================================
  Coverage     88.12%   88.12%           
  Complexity     2221     2221           
=========================================
  Files            84       84           
  Lines          7197     7197           
  Branches       1430     1430           
=========================================
  Hits           6342     6342           
  Misses          430      430           
  Partials        425      425           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

This is pretty cool!

BTW we have a similar job in NilAway that posts the diff of diagnostics produced by NilAway on stdlib on HEAD vs main for each PR: https://github.com/uber-go/nilaway/blob/main/.github/workflows/golden-test-run.yml

Example: uber-go/nilaway#281 (comment)

We have generally found this to be very useful (although it's partly because NilAway is less mature)

This is pretty cool!

BTW we have a similar job in NilAway that posts the diff of diagnostics produced by NilAway on stdlib on HEAD vs main for each PR: https://github.com/uber-go/nilaway/blob/main/.github/workflows/golden-test-run.yml

Example: uber-go/nilaway#281 (comment)

We have generally found this to be very useful (although it's partly because NilAway is less mature)

Very cool! I think once this bakes a bit we could implement some similar logic here. We would just have to grep out the NullAway warnings from the Gradle build output, though possibly we could just use NullAway's serialization support (thus far used only for NullAway Annotator) to make things more robust.

We would just have to grep out the NullAway warnings from the Gradle build output

You can use problem-matcher.json to annotate the pr. Caffeine’s build should fail unless you decide to mark the gha step as continue-on-error.

We would just have to grep out the NullAway warnings from the Gradle build output

You can use problem-matcher.json to annotate the pr.

Very cool! From what I'm reading, problem matchers help to annotate source code in the PR. But here, we have a PR on NullAway, and the errors / warnings we would be looking for would be reported on Caffeine's code. Would this approach still work?

Caffeine’s build should fail unless you decide to mark the gha step as continue-on-error.

Ah ok, so NullAway is running at error level now, cool! That makes things easier, we can just look for a job failure.

Would this approach still work?

I believe it would simply be unlinked to the file but still be an annotation attached to the pr. It might look like the ones you have currently wrt the pending ubuntu upgrade.