Add compilation errors & SAT GitHub annotations

[ghys]

No description provided.

[ghys]

Sorry I meant to open this PR in my fork 😠

[ghys]

So this is basically working (see the Files tab) with the following caveats:

• there can only be 10 errors & 10 warnings added by step (https://github.community/t/maximum-number-of-annotations-that-can-be-created-using-github-actions-logging-commands/16991/3)
• GitHub adds a "Unchanged files with check permissions" section which is kind of poor UX and cannot be collapsed or hidden ("Unchanged files with check annotations" is disruptive and should be configurable actions/toolkit#457).
• There is no way to scope the annotations to changed files only - that's because potentially you'd have e.g. unit test failures as a consequence of your changes.

What can be done is:

• fork the action to filter out the warnings and keep only the errors - this needs a fork because it's not offered as an option but should be easy to do
• fix the obvious errors as reported here ("There should be no empty lines between tags in a Javadoc comment of a method or constructor.")

Then the inline problem reports should be less noisy and only report what the user needs to fix to make the build pass.

Wdyt? @wborn

[wborn]

Thanks for having a look at this. 👍 I like the result and would also rather avoid having the "Unchanged files with check permissions" section show. Showing errors only would probably make the most sense now. The "10 errors & 10 warnings" is good enough for me.

I read that another issue is that the line numbers won't align if you use the files resulting from the merged branch. So that's why the example uses ref: ${{ github.event.pull_request.head.sha }}. But I would really want the code to be build using the merged branch so we know for sure there won't be any issues when merging PRs. Branches could be based on very old code too causing all sorts of issues. So then it is probably better to create another workflow for adding the annotations.

[wborn]

Many static analysis tools nowadays also support the SARIF format.

It seems you can also use these files to integrate with the GitHub code scanning, see:

https://docs.github.com/en/code-security/code-scanning
https://docs.github.com/en/code-security/code-scanning/integrating-with-code-scanning/about-integration-with-code-scanning

Might also be worth to look into what this exactly does and how well it works when PRs are created. 😉

[ghys]

So in the end I combined these two PRs into one:

• one that reports & displays Java compilation errors as annotations (example)
• one that reports SAT errors as annotations (example)

(Try Ctrl-F5 if the annotations don't show)

I eventually fixed some unrelated problems in this PR, that's because the action originally had a bug and was treating every problem as errors unless there were warnings - so info levels were treated as failures... If they are not wanted I can revert them.

[ghys]

https://docs.github.com/en/code-security/code-scanning
https://docs.github.com/en/code-security/code-scanning/integrating-with-code-scanning/about-integration-with-code-scanning

Those are interesting as well but it might be better to postpone them to another workflow dedicated to code checks?

[wborn]

Thanks a lot. 👍
I gave it a brief test in my own repo and it seems to work. 🙂
So let's test how it works for real!

[ghys]

If you think it'd be a good addition to other repos (notably openhab-addons) I can open similar PRs to those too.

[wborn]

Yes it would be nice to test it in the add-ons repo too!

I plan on adding GHA to more repos when all bugs are sorted out and we're happy with the features in the most active repos. 🙂 That prevents a lot of PRs to tune GHA everywhere. It might also be worth looking into reusing workflows if we add GHA to many repos.

[vivox80pro]

#16