Replicate Travis CI using GitHub Actions workflow

[ximon18]

This PR is a work-in-progress and is thus in draft state at present.

Known issues:

• It is currently deliberately triggered only on pull requests to the `molior-rebase' branch.
• Testing against latest the Go Lang master version is disabled as the GitHub Actions setup-go action doesn't obviously support installing such a version of Go.
• The workflow currently fails at the check target of the Makefile when make is invoked. It appears to be failing due to actual linting issues found in the code but a current aptly committer might be needed to verify that these failures are correct, or indicate if they should be ignored, unless of course there is a problem with the GHA workflow.
• The deploy capabilities of the original Travis CI setup are not yet replicated by this work. One step at a time ;-)
• Unlike the Travis CI build the workflow runs in Ubuntu 18.04 rather than Ubuntu 16.04 as 18.04 is the oldest GH Actions supports. If necessary the workflow could be configured to run in an Ubuntu 16.04 Docker container instead.
• It's currently using Python 2.7.17 which is quite old. I have no idea which version it should use, or perhaps it should just use the newest that works? This version was chosen simply by virtue of being the version that was installed in a local test with an Ubuntu 18.04 Docker image.

[lbolla]

Looking good so far! Thanks @ximon18

I can see errors in govet and golint: maybe we can silence those? Or do you want to fix them as part of this PR?

[ximon18]

Let's break down the failures:

• 8 cases of function name containing json should instead be JSON - well I assume I can "fix" that, but it could equally be marked to ignore as it's a style thing.
• 3 cases of composite literal uses unkeyed fields - based on this it sounds simple enough to fix but I'll have to dig into the code a bit, it's unclear to me if this is just a style thing or is actually something that should be fixed.
• 2 cases of ineffectual assignment to err (ineffassign) - that sounds like a potential error (i.e. there should be an effect), or is easily fixable/ignorable, but I don't know at this point which it is
• 1 case of misuse of unbuffered os.Signal channel as argument to signal.Notify - that doesn't sound good, but again I don't know if it's harmless or not.

Not being a Go programmer, not knowing the code base, and not having a history of committing to this project, it's hard for me to say what the right approach to take is for each of these. Any advice appreciated.

[randombenj]

@lbolla @ximon18

• I would propose to go for JSON instead of ignoring the linting if it makes go happier and that's the default.
• Also unkeyed fields sounds like it can 'just be implemented'
  For the later two I don't really know but would also suggest to try and fix those, run the tests and if it works keep the fix.

[ximon18]

Okay, the easy ones are done, I'll look at the others later when I have some more time.

[lbolla]

Thanks @ximon18 !

Don't worry about fixing the other ones. If you can ignore them, go for it and we can fix them on the target branch once this is merged.

[lbolla]

Thanks @ximon18 !

Don't worry about fixing the other ones. If you can ignore them, go for it and we can fix them on the target branch once this is merged.

Actually, I pushed a patch to fix those linting errors. Hopefully it should pass now.

[lbolla]

Now, as expected, "system tests" are failing. I will try to find the time to fix them as part of this PR.

[ximon18]

Thanks @lbolla for picking this PR up so fast and actively contributing to it, very appreciated.

[lbolla]

@ximon18 @randombenj OK, I cheated a bit, but now tests pass. I think we can merge this PR and improve later. Agree?

[ximon18]

Yes. The goal was to put the process in place, not to make the code being exercised be any particular sort of "green" :-)

I would push merge but there's no option to squash commits in this repository and I don't know what your policy is.

Please merge when ready.

[lbolla]

Thanks @ximon18 !

[ximon18]

@lbolla: One thing I/we forgot to decide was which events should trigger the CI workflow. Normally this might be on push to main and on any pull_request. As merged the workflow won't trigger except for PRs to the molior-rebase branch.