Question on Annotation Limits

Question

Question on Annotation Limits

Closed this issue 4 years ago · 4 comments

Thought I would ask, as you are clearly quite experienced in the Problem Matcher GH Action space!

I've discovered that there are annotation count limits imposed on GH Actions (e.g. 10 warnings / 10 errors per step). This is preventing me from receiving annotations on the single file modified by a prototype PR in a large project code base (with 600 GCC warnings annotated).

Have you run into this?

I was contemplating the addition of filtering by files touched in the PR (e.g. capture log messages to file, then filter them using get-all-changed-files before exposing to the Pattern Matcher). Downside here is that some issues triggered by a PR could cause warnings in entirely different files (at least for Clang-Tidy warnings, which I hope to move to next). But it's something. Also a single file could have 10+ annotations and we may miss out on annotations pertaining to changed lines in the PR.

Any ideas / experience here is welcome! Otherwise I'll attempt to hack my way through this.

I have PRs up for the documentation on Problem Matching regarding two of the issues I've run into:

I may add one more for your discovery on the fromPath clause (though I did not find it helpful for me due to limitations on multiline matches). I believe the fromPath logic strips the final suffix? So if you want a path /src/ prefixed to everything, you need fromPath="/src/anything-will-do" to overcome the suffix stripping (fromPath="/src/" does not work?).

Answer 1 · 2021-03-12T16:03:38.000Z

I've got a sane number of annotations now - I ended up using get-all-changed-files and grep to pre-filter the warnings being written to log for the gcc-problem-matcher.

But I still see no annotations on the PR. The gcc-problem-matcher is detecting the warnings (lines pre-pended with Warning and enumerated on the pipeline finalized output findings. But the PR is not showing the annotations.

This is a PR from a personal branch-on-fork to the upstream master (this is the nominal workflow for my team). I saw that you previously had issues with annotationsV2 w.r.t. some merge topologies. But I wouldn't expect ProblemMatchers to suffer there (in Issue they pointed you to this approach). Maybe I'll try a rebase to latest upstream master to ensure this isn't at play.

The file paths look good to me, but I'm going to try a couple more passes with mutated paths just in case that's at play for some strange reason.

Next step - maybe turn on debugging? Did you have any success with that avenue when exploring failures here?

I guess maybe it's time to go post on https://github.com/actions/toolkit for guidance.

Answer 2 · 2021-03-12T16:43:05.000Z

Rebase didn't help. Going to turn up the debug logging and see if that helps.

Also might try this on a branch Pull Request against my personal fork - to see if that changes anything.

Once I have debug logs I'll file an issue over at actions/toolkit.

Answer 3 · 2021-03-12T19:20:12.000Z

I've filed a GH Issue with the actions team with better detail / log pointers etc. I'll close this but please do chime in if you have any advice!

Thanks again =D

Answer 4 · 2021-03-13T12:25:55.000Z

So that was fun. Concluded in GH Issue - but it turns out that the paths captured by the problem-matcher infrastructure in GH Actions - are fixed up depending differently if you are emitting from within a container. And further, are dependent upon where in the container (it needs to be a volume mounted to the github workflow directory in your external runner VM). Very deceiving - I would have assumed that any matcher path relative to your repository would "just work".