all: add github actions workflow

[leighmcculloch]

What

Add GitHub Actions workflow that mirrors the CircleCI workflow.

Why

To simplify our CI workflows, make onboarding easier, and address some security improvements.

Known limitations

This does not include build steps relating to publishing artifacts and Horizon specific builds.

[leighmcculloch]

@bartekn No need to leave a review yet, but I wanted to let you know that it appears this works. I think the next step will be to:

1. Add building and publishing artifacts as a last step of this workflow that only runs for tags.
2. Add Horizon specific builds to a separate .yml workflow.

I think step (2) could happen independently of this PR and step 1, so the CircleCI file will become reduced to Horizon only specific builds after step 1.

Wdyt?

[leighmcculloch]

Actually, I think this could be merged, and publishing artifacts could be added. Merging this doesn't need to affect existing usages, PRs would only be blocked by CircleCI builds breaking. It might help us exercise Actions a little and see if we experience any big issues, before spending more time on this. Downside of merging this is it might be confusing that we have both CircleCI and GitHub Actions running.

I've marked this PR as ready for review.

[marcelosalloum]

LGTM!

I just have a question: it seems like we're adding some redundancy to the CI/CD setup, are we evaluating removing some of the CircleCI tasks later if we are satisfied with GH Actions?

[bartekn]

LGTM to merge and see how it works. We can add rest of the jobs from Circle later.

[leighmcculloch]

I separated check, build and test, which is more like what our existing CircleCI jobs do. It reduced the total GitHub Actions runtime from 8m to 5mXs which was a nice bonus. Technically we don't have a build step in CircleCI, but I think that was an oversight. It's helpful to make sure any packages that don't happen to have tests build successfully. Ideally all packages have tests, but on the off chance we ever have a package that only contains embedded data, or constants, etc, that aren't yet depended on inside the repo it might be useful, and I think it is helpful to see build failures separate to test failure output which is often long.

@bartekn any objection to this approach?

[leighmcculloch]

are we evaluating removing some of the CircleCI tasks later if we are satisfied with GH Actions?

@marcelosalloum Yup. This is exploration, although I expect we'll migrate all checks. I think since so many teams use this repo it would be a good idea to trial it first and not remove any test runs yet.

[bartekn]

Is it possible to prevent duplication of go/pg versions?

[leighmcculloch]

I tried removing the dupe with env vars, but failed to get it to work. Also, it was a little wonky because env vars have to be strings and these are arrays. I think it's not worth solving right now. According to the GitHub community forums they don't support yml anchors and aliases yet. If that gets added that'll probably be the ideal way to solve this.