ICU-12717 Create ErrorProne reports to find issues

[mihnita]

Checklist

• Required: Issue filed: ICU-12717
• Required: The PR title must be prefixed with a JIRA Issue number. Example: "ICU-1234 Fix xyz"
• Required: Each commit message must be prefixed with a JIRA Issue number. Example: "ICU-1234 Fix xyz"
• Issue accepted (done by Technical Committee after discussion)
• Tests included, if applicable
• API docs and/or User Guide docs changed or added, if applicable

[mihnita]

Generates two kinds of reports, but with the same data.

Sample here:

• https://mihai-nita.net/tmp/ep/errorprone1.html
• https://mihai-nita.net/tmp/ep/errorprone2.html

[jira-pull-request-webhook]

Notice: the branch changed across the force-push!

• .cpyskip.txt is now changed in the branch
• icu4j/tools/build/src/main/resources/com/ibm/icu/dev/tool/errorprone/errorprone.css is different

View Diff Across Force-Push

~ Your Friendly Jira-GitHub PR Checker Bot

[markusicu]

nice work!

[markusicu]

FYI
should be ok, since we already have JSON also under the MIT license
strangely, they differ somewhat -- JSON has a "notice" clause

@annebright @srl295 @macchiati @richgillam

[echeran]

suggestion: rename ErrorEntry to:

• ErrorProneIssue
• ErrorProneItem
• ErrorProneBug
• ErrorProneEntry
• IssueInstance
• DetectedIssue
• IssueLogItem

Just the word "Error" without fully saying "ErrorProne" sounds misleading or not fully specific.

[mihnita]

Done

[echeran]

question: Is it possible to refactor this to allow for another mode that products Markdown formatted output?

The reason is that Github doesn't have any easy or built in way to serve up HTML per workflow run. Anyone who creates reports & dashboards faces this problem . Even if you use Github Pages to display a dashboard, you really only want to generate that from the upstream repo's main branch. Which means that for PRs, for every commit that you push to a PR before you merge, you don't really have anywhere to put the reports generated per commit.

The good thing is that GHA Job Summaries does support the ability to put a report somewhere regardless of which branch it comes from... It just needs to be in the form of Markdown. And the "somewhere" that it supports as the destination for the report is the workflow instance's summary page.

The Markdown formatting is Github Flavored Markdown (GFM). It will end up looking similar to what you have in HTML format, but not quite as fancy or feature-ful. As a potential user, I can live with less fancy formatting if I can have the convenience of having some type of accessible usable report on every push.

[mihnita]

question: Is it possible to refactor this to allow for another mode that products Markdown formatted output?

Yes. But we can't do JavaScript. So we can't sort the table(s)
The second style (errorprone2.html) would probably work even without sorting.
But the 1st style (errorprone1.html) would not.

I was not thinking about this for regular PRs, but for something like a nightly build.
You can only enable something like this for each PR after we get the number of issues down to virtually nothing.
Otherwise we need something a lot fancier.
We would need to keep a history (before / after PR) and the ability to filter older failures.
If not, we would have to report something like: before your change we had 976 errorprone issues, with your PR we have 980 issue. Good luck finding them :-)

[mihnita]

way to serve up HTML per workflow run

Thinking about it, that feels weird. There should be a way...

Anyway, that is something I wanted to talk to you about.
When to run it, and where to post the results.