Add GitHub actions

[MSP-Greg]

Ubuntu 16.04 - Ruby 2.3, OpenSSL 1.1.1

Ubuntu 18.04 - Ruby 2.4, 2.5, 2.6, OpenSSL 1.1.1

macOS - 2.4, 2.5, 2.6, OpenSSL 1.0.2

Windows - Ruby 2.4, 2.5, 2.6, OpenSSL 1.0.2 & 1.1.1

Commits:

1. 'Add GitHub Actions- Ubuntu, macOS, Windows' - adds Actions, MinGW jobs fully update MSYS2 toolchain and add correct OpenSSL files.

2. 'extconf.rb - update for new MSYS2, libssp' - current MSYS2 tools require using libssp.

3. 'OpenSSL::TestSSL#test_finished_messages - gracefully close client' - test would not pass on MinGW build using 1.1.1d. Added two lines to close client

[MSP-Greg]

Re the third commit, I recall with OpenSSL 1.1.0 or 1.1.1 (vs 1.0.2) the following issues with CI:

1. The callback/notification order changed.

2. Servers would not close invalid connections, but would not respond to them. Typically, this was clients with invalid credentials or TCP connections to an SSL server.

3. As I found with the test, the test was closing the client before the server callbacks/notification were complete.

Tested locally using OpenSSL 1.1.1d and
ruby 2.7.0dev (2019-10-26T07:27:23Z master ad9c713728) [x64-mingw32]

[bdewater]

Why 10 and not 1 as in the example? We're not going to be doing anything with the history?

[MSP-Greg]

Because several CI builds could be queued up at the same time.

[bdewater]

According to https://github.com/actions/checkout and https://help.github.com/en/github/automating-your-workflow-with-github-actions/events-that-trigger-workflows every invocation of the action checks out a specific SHA, which includes any previous changes up to that point. I don't see how those other 9 commits will be used no matter any queueing going on?

[MSP-Greg]

https://github.com/actions/checkout/blob/master/action.yml#L17-L18

Specifically, 'defaults to no limit'

[MSP-Greg]

Sorry, earlier I was distracted. Without fetch-depth, all commit history is retrieved via git fetch. So, it should be larger than the maximum number of commits that one expects to be in the CI 'pipeline' at an given time.

Without it, large repos can take longer to retrieve...

[bdewater]

I'm not arguing against doing a shallow clone, but against using a depth of 10 instead of 1 🙂 Every queued build will run the action and get their own history up to the SHA checked out. There's no need for every build fetching 9 more commits of history. They won't be used, there's no sharing going on.

Also see actions/checkout#22 where further optimizations are discussed.

[MSP-Greg]

I think ruby/ruby did their own command, similar to what's shown, as they have a lot of tags & commits.

Regardless, the longest checkout step when run in my fork took 5 seconds. We've spent more time here than the next several commits/pr's would take...

[ioquatix]

@bdewater please submit an updated PR after this merged and we can confirm your thoughts, thanks everyone for the discussion and work.