Vega-strike-engine-source: Move from Travis-CI.org to GitHub Actions

[BenjamenMeyer]

Travis-ci.org is closing down with everything moving over to Travis-ci.com. Generally this would be okay; however it travis-ci.com uses a credit based system (10 credits per minute). Based on some rough estimations we run about 300 minutes (3,000 credits) per build for the Vega Strike Engine Source; master will reduce this some as we have dropped some builds. If Travis-ci.com did a recurring allotment each month we could easily figure out our monthly needs, adjusting the allotment accordingly. That said, it's not clear that the open source credits from Travis-ci.com would apply to GitHub Organizations (still waiting to hear back on an email to support). All said, we'd likely need to request 1,000,000 credit chunk allotments to cover us for a sufficient time period across our repositories. All-in-all it's not as attractive.

Doing some research we have a few options:

• move to Circle-CI (also credit based, don't think they have an open source policy though...so we'd run out of our credits quickly and be stuck each month unless we paid for more credits)
• move to our own infrastructure (we have to pay for our infrastructure but we get unlimited usage...problem is we don't have much income yet to support doing so).
• move to GitHub Actions (free for public repos, otherwise credit based as well from what I can tell at GH Actions Billing Info); they also have a migration guide.

GH Actions seems to be where we want to go for now at least. It would be good to identify any "actions" we need to do and survey the GH Action Marketplace to see if there are any that we can utilize or if we need to build our own:

• [ ] CMake Build Runner GH Actions Search
• [ ] CMake Test Runner GH Actions Search
• [ ] CMake Package Runner GH Actions Search
• [ ] Coveralls.IO Integration or other code coverage replacement
• [ ] GitHub Assets Uploader (for releases)

[stephengtuggy]

Note that I believe GitHub actions also lets you host your own "runners" on your own infrastructure. If we can't get GH Actions for free, maybe we can host our own runner on DigitalOcean.com or something.

[Loki1950]

As @BenjamenMeyer said would prefer our own infrastructure with that in mind would our web sites server be able to handle the load after a proper reconfiguration @www2000 might decide to expand his support to include that.

[stephengtuggy]

@Loki1950 I'm not sure it's a good idea to have our web server do too many jobs. Doing the builds will be quite a heavy task by itself.

[BenjamenMeyer]

Running Jenkins, etc is intense, requires lots of RAM and multiple systems in a cluster. It could be done on a k8's cluster but that's all beyonce our current budget.

GH Actions should be sufficient for now.

[www2000]

@Loki1950 i agree with @stephengtuggy about the server load current memory use is around 2GB of 4GB that is install.
And my hosting provider is not happy if we build vegastrike one's a day (the server is a VPS).

[Loki1950]

Just wanted to be sure that we covered all the angles before we commit to any changes.

[BenjamenMeyer]

I did get a reply from Travis-CI Support; but it wasn't terribly helpful in answering my question. As it's already apparent we need to migrate to something else I'll just let it close out. Sad to see Travis-CI go - it's been a great platform for years.

[stephengtuggy]

I did get a reply from Travis-CI Support; but it wasn't terribly helpful in answering my question. As it's already apparent we need to migrate to something else I'll just let it close out. Sad to see Travis-CI go - it's been a great platform for years.

@BenjamenMeyer Agreed.

[BenjamenMeyer]

We have 0.7.x engine moved over. Still need to do master. We lost Mac builds in the process so we'll have to add those back. We might get Windows builds too now as well (Win Server 2019); but don't know what tool chain we'll be getting.

[BenjamenMeyer]

The engine build matrix is moved over and travis-ci is now disabled; CodeQL needs to be migrated still.

[stephengtuggy]

Note that CodeQL doesn't seem to be in the GitHub Actions Marketplace list. I'm not sure why not. If we want to analyze our code for security vulnerabilities, we may need to use a different code scanner that is available in the Marketplace.

[BenjamenMeyer]

We could also write a CodeQL action to use. It doesn't have to be in the GH Actions Marketplace to be used; they're just packages to help folks do common activities. Surprised CodeQL doesn't have one already.

[stephengtuggy]

@BenjamenMeyer I think the CodeQL one is in beta. You have to sign up for the beta program to see it (in the Marketplace at least).

[stephengtuggy]

Either that, or they're phasing it out.

[BenjamenMeyer]

@stephengtuggy ok. Not saying we have to use that one. We should enable the build in tooling (dependsbot?) at the very least. If we can identify other tools and linters that would be good too.