Consider switching to GitHub Actions for automated testing

[lukpueh]

Description of issue or feature request:
We switched from automated testing on Travis CI (Linux) and Appveyor (Windows) to GitHub Actions in our sister-project in-toto-golang (see in-toto/in-toto-golang#72), mostly due to availability concerns about Appveyor and because it seems appealing to configure only one service for all platforms.

Let's consider switching here too and testing on more platforms than we currently do.

Current behavior:
Use Travis CI for automated tests on Linux (no tests for Windows and Mac OS)

Expected behavior:
Use GitHub Actions instead and also test on Windows and Mac OS.

[joshuagl]

Given how slow Travis has been this week and how slow AppVeyor has always been, as well as the inconsistency between CI setup between the two platforms, I suggest we don't even need to consider this. Let's do it!

I think GitHub actions might be a bit easier to replicate/debug locally, instead of having to push a commit and see what errors CI throws. Does that match your experience @jku?

[lukpueh]

Related: in-toto/in-toto#407 and theupdateframework/python-tuf#1195

[jku]

I think GitHub actions might be a bit easier to replicate/debug locally, instead of having to push a commit and see what errors CI throws.

Uh, I was hoping that would be the case but local execution is not something Github explicitly supports and getting it working seemed too much hassle for at least the one workflow (https://github.com/nektos/act).

This worked reasonably well as a loop though (not quite REPL but...):

• edit the workflow file directly in the github ui in a testing branch
• trigger the action from that branch manually
• check the results

The only caveat is that the workflow must exist in main branch: otherwise it does not seem to appear in the UI at all.

[lukpueh]

Thanks for the report, @jku. nektos/act is probably worth exploring at some point (maybe an SSLAB stundet task?)
In the meanwhile I think the 1-service-for-all-platforms + reliability arguments still make a strong case for the switch.

[jku]

oh and a major benefit I didn't mention: testing actions in a fork is simple. In my case I just enabled issues in my fork and could then test issue opening from actions there without creating test issues in the project itself

[lukpueh]

Also consider injection vulnerabilities reported in https://crbug.com/project-zero/2070

[jku]

Considered and implemented in PR #324

Related still open issues: #325, #326