Panic when a test times out

[fmeum]

What type of PR is this?

Feature

What does this PR do? Why is it needed?

By calling panic when a Bazel test times out, which is indicated by Bazel sending a SIGTERM, stack traces of all Go routines are printed, similar to the behavior of native go test.

Which issues(s) does this PR fix?

Fixes #3746

Other notes for review

[fmeum]

CC @rickystewart

[rickystewart]

Ping on this :) IMO this is a colossal UX improvement over the status quo.

[tyler-french]

LGTM. Nice work making the signal channel have a buffer of 1. I do wonder if there is a more idiomatic way to handle a stack trace with runtime.Stack and os.Exit(), but panic is probably good for simplicity.

[fmeum]

I do wonder if there is a more idiomatic way to handle a stack trace with runtime.Stack and os.Exit(), but panic is probably good for simplicity.

Since the testing package itself uses panic, I see value in using the same technique. Unfortunately we can't get the list of running tests as it does appear to be internal to that package.

[timonwong]

FYI: I came across goleak problem after rules_go v0.44.0.

Since bzltestutil.RegisterTimeoutHandler() is registered before TestMain, I have to use goleak.IgnoreCurrent() to workaround that, for example:

func TestMain(m *testing.M) {
	goleak.VerifyTestMain(m, goleak.IgnoreCurrent())
}

[hawkingrei]

FYI: I came across goleak problem after rules_go v0.44.0.

Since bzltestutil.RegisterTimeoutHandler() is registered before TestMain, I have to use goleak.IgnoreCurrent() to workaround that, for example:

func TestMain(m *testing.M) {
	goleak.VerifyTestMain(m, goleak.IgnoreCurrent())
}

I meet this problem, too.

@fmeum PTAL

[fmeum]

This will be addressed via a default ignore rule in a future goleak release - rules_go can't cancel the go routine in time for the leak check.

Cc @linzhp

[linzhp]

You can call IgnoreTopFunction too, which is less dependent on lifetime of the goroutine that rules_go creates