Replace Travis with Github Actions & Plan new CI/CD pipelines

[mindsolve]

Situation

• Travis CI has changed its pricing model from automatically free for Open Source to a limited manual verification approach, in which the project has to request pipeline credits.
• Github Actions has been introduced as an integrated way of running CI/CD pipelines.
• GH Actions is completely free for public projects

Due to this situation, and personal experience showing the maturity and widespread support for GH Actions, I would suggest moving from Travis CI to GH Actions.

While "simply" moving might be an option, this would also be the ideal point to retink our requirements and whishes for our CI/CD pipelines.

Based on analyis of the existing CI configuration, I have determined the current status to be as follows:

Current pipelines:

• Travis CI:
  • Building of the C#, Go, Java and Ruby versions in all PRs
  • Successful build as requirement for PR merge
• AppVeyor:
  • Building of the C# version in PRs
  • Successful build as requirement for PR merge
• CodeFactor:
  • Static code analysis for many languages
  • Successful check as requirement for PR merge

Proposal:

• CodeFactor (same as before)
• GH Actions:
  • Pipeline for Commit/PR build
    • Successful build as requirement for PR merge
    • Should support all language "flavours" of minestat
  • Pipeline for End-to-End tests (long-term goal)
    • Check functionality of flavour against list of server versions
    • Successful checks as requirement for PR merge
  • Release pipeline (long-term, to be discussed)
    • Pipeline for automatically packaging a new release of a specific flavour and deployment to repositories (e.g. npm, pypi, nuget)
    • Triggered by specific commit message by authorized user

@ldilley: Did I correctly interpret the current configuration? What do you think about the proposal, and what would you want the ideal CI/CD pipeline to do?

Progress

• Successful build required for PR merge
• Covered for languages supported by CodeQL
• Perform protocol tests against a server which must pass for PR merge
• Handle the publishing of npm, NuGet, PyPI, etc. packages (partially validated)

[ldilley]

This looks like a solid plan and does indeed capture the current configuration. I am most intrigued by the automated testing and packaging.

[ldilley]

Updates:

• Successful build as requirement for PR merge
  I've added the CodeQL analyses as status checks required for PR merges.

• Should support all language "flavours" of minestat
  CodeQL supports C#, Go, Java, JavaScript, Python, and Ruby. Perl, PHP, and PowerShell are not currently covered.

• Check functionality of flavour against list of server versions
  If this functionality is still desired, we'll have to write our own tests and determine a way to reliably query servers running each SLP version along with Bedrock/PE.

• Pipeline for automatically packaging a new release of a specific flavour and deployment to repositories (e.g. npm, pypi, nuget)
  We have a decent start on this item thanks to @Ajoro, but there are likely some kinks to work out as we've observed with the NuGet publication.

[mindsolve]

We made very good progress here, thanks Ajoro!

Regarding "Check functionality of flavor against list of server versions":
This is already in development, though it's still going to take a while, as I am not as far with the project as I would like. I am going to report back when I've made significant progress 😅.