Matchers: Error annotations catch things that are not errors and not even in Go code

[JasonGross]

Consider the (totally valid) makefile:

all: foo
	echo Done

include Foo.mk

Foo.mk:
        printf 'foo:\n\techo foo\n' > $@

On the first run of make, this generates

Makefile:4: Foo.mk: No such file or directory
printf 'foo:\n\techo foo\n' > Foo.mk
echo foo
foo
echo Done
Done

There isn't really a good way to suppress this warning (see this StackOverflow question I asked) without massively complicating the Makefile. I don't mind seeing this warning on the first make. However, my github actions go job decides that this is an error (it's not; it's non-fatal), and annotates every single pull request on my repository with an error on the relevant line on the Makefile. Please fix the annotation to not do this.

[bryanmacfarlane]

I think this action does the right thing. Perhaps the issue is service side which turns output into warning and error annotations. @joshmgross to verify whether there's anything we can do action side.

[JasonGross]

No, I'm pretty sure this is an issue with your matcher being overzealous:

setup-go/matchers.json

Line 7 in 1c06f0e

"regexp": "^([^:]*: )?((.:)?[^:]*):(\\d+)(:(\\d+))?: (.*)$",

This claims that every single output line containing two :s separated by a number an followed by a space is an error in the file that comes before the first colon.

[bryanmacfarlane]

Ahhh. OK. Thanks @JasonGross

@thboop has another issue on the matcher so maybe he can look at both together.

[bryanmacfarlane]

@JasonGross if it's causing problems there's also a way to disable the problem matcher.

https://github.com/actions/toolkit/blob/master/docs/commands.md#problem-matchers

We added that feature since the scope of a problem matcher is a job and scripts / steps downstream could get false hits.

[bryanmacfarlane]

I think the solution is to have a much tighter regex for compile errors and then if there's things it misses, problem matchers supports having multiple matchers.

I'll have a PR soon for the v2-beta lineage.

[JasonGross]

@JasonGross if it's causing problems there's also a way to disable the problem matcher.

https://github.com/actions/toolkit/blob/master/docs/commands.md#problem-matchers

We added that feature since the scope of a problem matcher is a job and scripts / steps downstream could get false hits.

Oh, neat! Thanks! Do you know why this isn't documented at https://github.com/actions/toolkit/blob/master/docs/problem-matchers.md ?

[bryanmacfarlane]

We can add there. In the meantime, I'm also working on a better solution.

[bryanmacfarlane]

@JasonGross I have a PR that might help: #48

You can try it out with use: actions/setup-go@matcher

I added tests but it would be great to verify before merging.

[JasonGross]

I'm running a test here: https://github.com/mit-plv/fiat-crypto/pull/703/checks?check_run_id=547046526

[JasonGross]

Seems to work well, thanks!

[bryanmacfarlane]

Thanks for validating. This is now in setup-go@v2-beta and soon to be v2. If you're using the matcher ref from the PR, you may want to update to v2-beta (that won't go away).