Cxbx-reloaded: Migrate to GitHub Actions as sole CI provider

[GXTX]

This comes after noticing a pattern of having to update CI configurations for tiny details. Currently CXBX-R supports 3 different CI providers, this issue is to track and gather thoughts about moving to just GitHub Actions. From my eyes at least Actions is actively developed and actively supported, travis until late last year didn't even have a Ubuntu 18.04 runner and still defaults to using 16.04.

Benefits

• Consolidated support requirements
• No need to create 3rd party accounts (note AppVeyor with it being attached to LukeUshers personal account)
• No need to give additional org permissions to 3rd party providers

[LukeUsher]

Going forward, I propose that we

1. Drop all CI except github actions
2. Configure actions to build artefacts for all branches and PRs
3. Configure actions to publish artefacts from master to Github Releases, no other branches should be published
4. Once all this is configured, merge develop into master, and delete the develop branch.

All work should continue based on master.

[RadWolfie]

Going forward, I propose that we

1. Drop all CI except github actions

As in deactivate CIs which I am fine with it.

...

1. Configure actions to _publish_ artifacts from master to Github Releases, no other branches should be published

Tags should generate official release whilst merged pull request (to master) should mark as snapshot releases (aka pre-release base on GitHub's description). Since I notice xqemu devs talked about the artifacts aren't accessible to public unless login to the site.

[RadWolfie]

See #1698 for possible actions to use for this task.

[Margen67]

Going forward, I propose that we

1. Drop all CI except github actions

As in deactivate CIs which I am fine with it.

If we only deactivate them they will still need to be maintained, otherwise they are useless.

[RadWolfie]

Little to no maintenance requirement for third-party CIs. GitHub Action's workflow is fairly new and of course will have more maintenance requirement.

What will cause "more" maintenance to third-party CIs configuration are anything other than builds system. The contributors, which is not us aka the devs, will be responsible for maintaining deactivated CIs configuration file. Mostly the work will on "artifacts" and rarely CMake's generator. That's it.

[LukeUsher]

Why should the responsibility of managing CIs that people who fork the repo fall on us?

We should only manage and maintain the CI systems that we use.

If any third parties maintain their own forks, setting up CI should be up to them, not us.

[RadWolfie]

Why should the responsibility of managing CIs that people who fork the repo fall on us?

Look at the commit histories for each CI files:

• Travis CI
• Azure Pipelines
• AppVeyor CI

How often do we keep changing to these files other than "artifacts" and "excludes" changes?
Well, we all know the answer even don't realize after looking at the facts.

We should only manage and maintain the CI systems that we use.

Right, there's no reason to delete the inactive CI configuration files when there's nothing wrong with it. Aka being a kneejerk to forked repo users. The only time we should delete CI configuration files if they're very bad setup. So far, they're not even bad at all. And just now became slightly bad by adding more complexity work when it's not even necessary.

If any third parties maintain their own forks, setting up CI should be up to them, not us.

In my opinion, it's better to have "ready to use", aka production, configuration files which doesn't have any complicated configuration which we had "tested" and is known to work every time for very long time.

If you don't agree with me for "ready to use" configuration files, aka KISS method. Then I guess we can revert CMake back to Visual Studio's solution files and let someone else re-create the project's setup with a different compiler or IDE.

[RadWolfie]

Btw, I am done with this discussion about want to delete CI files.

[Margen67]

Going forward, I propose that we

1. Drop all CI except github actions

2. Configure actions to build artefacts for all branches and PRs

3. Configure actions to _publish_ artefacts from master to Github Releases, no other branches should be published

4. Once all this is configured, merge develop into master, and delete the develop branch.

All work should continue based on master.

Work is being done on this here: #1854

[GXTX]

@Margen67 once #1854 is merged I think it would be a good idea to see a 2nd PR to update the README.md adding the badges and removing the other 3, or attach these changes into the current PR - which is probably the better option.

[Margen67]

I added a GitHub Actions badge to the readme in that PR, but it won't work until it's on the master branch.

[GXTX]

CI changes were introduced in #1854. I'm going to keep this issue open as it sort of turned into a meta issue which aims to change multiple things (not just the title), will close once develop is merged back into master.

[GXTX]

And rebased in #1870, thanks guys!.