How to Reduce Our CI and Build Maintenance Overhead

[stephengtuggy]

In the vegastrike/community chat room, user loonycyborg made a good point, that:

CI work shouldn't definitely be so voluminous that you have to pick it as alternative to actual gamedev

... which is kind of what has been happening lately, at least for me in some cases.

What would be some specific strategies for how to remedy this situation? Should we consider packaging the game in Flatpak format instead of building it for different individual Linux build systems? Should we make vcpkg our dependency manager across the board, on Linux and macOS, in addition to Windows?

What other ideas do you guys have?

[loonycyborg]

wesnoth/wesnoth#7559 <- you might consider doing something like this, no longer need anything distro specific then.

[BenjamenMeyer]

Flatpak and Snap don't really solve the problem. They can actually make it worse. We had someone looking at Flatpak already and there's issues with its platform layer detecting what we support for OpenGL among other things so it would be a heavy lift to get them working. I suspect Snap won't be much different.

Our issues right now are not Linux, but Windows and Mac which are not solved by Flatpack or Snap either.

[BenjamenMeyer]

While generally I'd agree, there are, however, times when it becomes necessary to focus on CI to help things along. As we're getting two major platforms added to our support (Mac and Windows) we're kind of in one of those CI focused phases. Our Linux stuff which supports multiple distros is pretty stable; sure it has an occasional issue but nothing that is causing us a lot of heartache. Rather it's Windows and Mac instability that is causing the most issues, which is kind of expected as we learn those platforms since the team is very Linux knowledge heavy and in some cases cannot troubleshoot Windows/Mac stuff locally.

[stephengtuggy]

Fair enough.

[stephengtuggy]

Update: So the CI builds seem to be quite a bit more manageable lately. Partly there were just a bunch of hurdles that came up, all in a short period of time, such as GitHub's deprecation of GH Actions workflows running on Node.js 12 and 16, for example. And partly, I was just trying to add too many different builds, numerically. The sheer number of different CI builds made a much bigger difference than I had anticipated.

The goal of the CI and build systems has always been to serve the larger aims and needs of the Vega Strike project and community. It was supposed to help us reestablish and maintain compatibility with the relevant OS platforms, to help drive adoption, and to allow more users to play the game(s). The CI builds were also meant to help us maintain a high bar of code quality, and of game functionality.

I'll admit I got a little carried away with adding CI builds, around June of last year. I think I've learned my lesson. 🙂

Thanks, guys, for all your hard work and patience. I hope we can continue to keep Vega Strike alive and moving forward for some years yet to come.

[BenjamenMeyer]

GH Actions does make it easy to add more platforms....too easy perhaps. and CI systems have come a long way since VS started back around 2000...the original devs probably never imagined being able to do this at that time.

Live and learn. 🏫