xt0rted/problem-matcher

A GitHub Actions template to easily add or remove a problem matcher to workflows

GitHub Actions Problem Matcher

A GitHub Actions template to easily add or remove a problem matcher to workflows.

Setup

This template has been designed so the only code change you should have to make is in problem-matcher.json and optionally the tests for it. When editing the problem-matcher.json you should set the owner name to the application and/or report style being matched. Examples of this are eslint, eslint-compact, or eslint-stylish.

Make sure to also update the action.yml and package.json files.

Sometimes report messages might not include a line or column number and your regular expression doesn't pick those lines up. To help avoid those situations tests are provided to give coverage to the regular expression.

A useful resource to view and test your regular expression is regex101.com.

Usage

on: push
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: xt0rted/problem-matcher@v1
      - run: echo "Run some tests that will be picked up"
      - uses: xt0rted/problem-matcher@v1
        with:
          action: remove
      - run: echo "Run some more tests that shouldn't be picked up"

Options

Name	Allowed values	Description
action	add (default), remove	If the problem matcher should be registered or removed

License

The scripts and documentation in this project are released under the MIT License

problem-matcher's Issues

Consumer of GH Action appears unable to find dist/ build artifacts?

Big thank you for this awesome Template! Super userful and such high quality work. Excellent comments, test coverage.

I'm working on a GCC problem-matcher with support for fromPath annotations. I've taken your Template problem-matcher and made one commit's worth of modifications Here.

My repo appears to be going through post-submit compile and test fine - e.g. see Here.

I have a super simple secondary repo that is intended to prototype this fromPath GCC warning capability. When I submit a PR intended to trigger the findings - I'm getting an error on fetch of electronjoe/gcc-problem-matcher-ts.

Error: File not found: '/home/runner/work/_actions/electronjoe/gcc-problem-matcher-ts/v1/dist/index.js'

Here is an example GH Action failure that uses the above electronjoe/gcc-problem-matcher-ts.

I'll keep exploring! I'm really a typescript greehorn. Some of my questions I'm working to answer msyelf include:

• I'm finding that when I rpm run build in gcc-problem-matcher-ts
  • what I infer is the final index.js we want is stored to lib/ (not sure why not dist/)
• The path being attempted by the gcc-problem-matcher-ts load surprises me
  • Why does it expect the action in gcc-problem-matcher-ts/v1/... How is that generated?
• I looked at build artifacts from the repo e.g. on my v1 tag
  • As I wondered if perhaps there was a TS compile and artifact generation going on?
  • But I do not see anything other than source code being output (no javascript dist/)

Welcome assistance! Hope you are having a great week.

Switch back to npm instead of yarn

Newer versions of npm work just as good as yarn so there's no need for this anymore.

Question on Annotation Limits

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:

• Note annotation limits in Problem Matchers documentation
• Note multiline match limitation in Problem Matchers documentation

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?).