Test on Go 1.13 and 1.14

[at-wat]

Test on Go 1.13 and 1.14

[at-wat]

Not tested yet

[at-wat]

Configuration is valid. But seems causing test failure.

[Sean-Der]

@at-wat Feel free to send any test failures my way! happy to split the work :)

[at-wat]

https://travis-ci.org/pion/webrtc/builds/659740262?utm_source=github_status&utm_medium=notification
I restarted this a few times. i386 and WASM on Go 1.14 is continuously failing. I haven't seen the details yet.

[at-wat]

One of the failure at there is TestPeerConnection_Renegotation_AddTrack.
It also fails on local Go 1.13. Seems not a Go version specific.

[Sean-Der]

@at-wat this has been known to be flakey. I would disable (and I think we already have a ticket) I will work on fixing!

Would you be ok with me moving us from Travis to Github Workflows? I am want to learn it, but don't want to move if it is worse. I don't have any experience, so want to check with you first :)

[at-wat]

The main problem of GitHub Actions for us is that it doesn't concurrently run matrix build.
Matrix build is run in series and if one target fails, remaining targets will be canceled.

Another one problem is that Action never triggers other Action to avoid endless loop.
#16 will not work if CI is run on GitHub Actions.

And, I believe that getting flaky test result on Travis-CI just means the test or library is not fully stable.
I guess main cause is load of the actual CPU. So, error on Travis may also happen on some real use cases.

[at-wat]

pion/webrtc#1039 occurs frequently.

Goroutine leaks on WASM Go 1.14.

=== RUN   TestNewBundlePolicy
--- PASS: TestNewBundlePolicy (0.00s)
=== RUN   TestBundlePolicy_String
--- PASS: TestBundlePolicy_String (0.00s)
=== RUN   TestConfiguration_getICEServers
=== RUN   TestConfiguration_getICEServers/Success
=== RUN   TestConfiguration_getICEServers/Success#01
--- PASS: TestConfiguration_getICEServers (0.00s)
    --- PASS: TestConfiguration_getICEServers/Success (0.00s)
    --- PASS: TestConfiguration_getICEServers/Success#01 (0.00s)
=== RUN   TestDataChannel_Open
=== RUN   TestDataChannel_Open/handler_should_be_called_once
    TestDataChannel_Open/handler_should_be_called_once: util.go:37: Unexpected routines on test startup: 
        goroutine 6 [waiting]:
        runtime.gopark(0x0, 0x0, 0x0, 0x1)
        	/home/travis/go/src/runtime/proc.go:304 +0x22
        runtime.handleEvent()
        	/home/travis/go/src/runtime/lock_js.go:235 +0xf
        runtime.goexit()
        	/home/travis/go/src/runtime/asm_wasm.s:428 +0x1

It seems not a leak in our code.

[at-wat]

All nested t.Run has runtime.goexit() routine at beginning.
pion/transport#62 will fix it.

[at-wat]

It should be ready now.