Galaxy

[dcvz]

This PR moves our CI system to use Github Actions.

Why

The main motivation driving this is being able to further scale. Leveraging Github Actions allows us to make use of their "free to open source" resources. This means we might be able to support more platforms or make use of matrices to perhaps build with different compilers for different platforms, or build and support variants.

Other Benefits

• One eventual benefit might be to not have to pay for our current Jenkins master node.
• Integrated into the platform we're already using, making it easy to see CI runs
• Also, when more ports are supported, ports also won't have to compete for building time.

Potential: If we find a better way to do assets, in theory any public fork of this repo will automatically have CI. Otherwise individual devs can add a machine to their forks to act as asset builders.

Limits

What limits do we have when using Github Actions? Well, in theory it is free to use for any open source project (meaning the repository is public). But there are a few limits to know about:

• The number of concurrent builds is 20 and 5 concurrent macOS builds. Better than we can currently do, but still good to know about
• Artefacts can only be stored up to 90 days. Again better than what we currently have, but a good to know

Machine Specs?

Are Github machines fast? No. They are actually quite weak compared to the top notch machines we have in Jenkins so builds take longer.. around 12-25 minutes (macOS and Windows take the longest).

However, as part of this effort I have added in a compiler cache (ccache) that makes builds 65%+ faster. The slowest builds taking up to 4 min or so, when healthy cache is available. Given the bandwidth this project gets, cache should usually be available for builds.

Generating Assets

How does generating assets work? The workflow first generates assets (similar to what we currently do) and for that step and only that step, it uses our self hosted machines. Generating assets takes around 1 minute, making it pretty fast and unlikely to be a bottleneck. When this ships we will have three macOS machines acting as asset builders.

Possible Migration Plan

The moment this is merged in it will begin to work and run on branches that contain these changes. Before this gets merged we should make sure we have at least 3 asset building machines in the organization. We can keep Jenkins running for branches that are not yet updated and for private forks (Ghostship).

Cons

• Makes it harder to move away from Github (if we ever want to)
• Machines are technically slower (but mitigated with ccache)
• Tricker to do private repos (since its only free for open source)

[dcvz]

@dcvz how goes progress with this? Sorry I've been too distracted with other stuff to help out much on this yet

Pretty well @garrettjoecox -- macOS and Windows are building with ccache making subsequent builds faster. Was in the process of trying to get ccache going in the other workflows when I paused work on this.

[briaguya-ai]

i'd prefer keeping nintendo out of the build names if possible

[Kenix3]

Looks good to me.

So we can repurpose our Jenkins agent for this and thus we no longer need that master server anymore at all?

@sholdee we'll want to talk about backing up the Jenkins master server before shutting it down, but moving to GitHub doesn't depend on that.

[sholdee]

Nice work! I think this is a good idea.