Annotated github ci output

[jbergstroem]

It would be great to get typos annotated as part of a PR check. The most straightforward path is probably through a problem matcher - it could look something like this:

{
  "problemMatcher": [
    {
      "owner": "typos",
      "applyTo": "allDocuments",
      "pattern": [
        {
          "regexp": "^(error|warning): (.+)\\n  --> (.+?):(\\d+):?(\\d+)?$",
          "file": 3,
          "line": 4,
          "column": 5,
          "severity": 1,
          "message": 2
        }
      ]
    }
  ]
}

Happy to open a PR if it is desired!

[epage]

We had annotations in the past. I'm assuming they aren't working. We were using json output for it

https://github.com/crate-ci/typos/blob/master/action/entrypoint.sh#L64

I think I'd prefer using json over a problemMatch

Alternatively, there is also #594

[jbergstroem]

We had annotations in the past. I'm assuming they aren't working. We were using json output for it

Oh! Yeah, I haven't seen it. I can take a look at fixing that instead then.

[jbergstroem]

We had annotations in the past. I'm assuming they aren't working. We were using json output for it

Oh! Yeah, I haven't seen it. I can take a look at fixing that instead then.

Just checked - the output looks just fine to me. I think the "problem" is that the warnings that typos generate for files in my repository weren't part of the pull request. I guess that's one benefit of a problem matcher ("applyTo": "allDocuments")

[epage]

For most projects I've been on, we've preferred to not touch unrelated code in the review but to save those for another PR. This means annotating code unrelated to the PR is unactionable. By providing unactional annotations, we are creating extra noise for people that would make them more likely to ignore all annotations or turn off the tool.

Unless there is additional information, then I'm going to assume the annotations are working as expected, that we don't want to expand the scope of the annotations, and for any further change in this area, we'd more likely want #594, I'm leaning towards closing this.

[jbergstroem]

Appreciate the consideration! Thanks for your input.