Why not move to less proprietary build infrastructure?

Game Talk The Drawing Board
1

May I ask why you ported the release process over to Microsoft GitHub in particular as opposed to

  1. Fixing the existing build server;
  2. Porting to a build platform that is not proprietary, not closed-source and not a de-facto monopoly?

The way I see this, Cataclysm just became further vendor locked-in to the GitHub monopoly and proprietary software.

EDIT: long list of ethical issues with GitHub in particular and Microsoft in general: humanacollaborator/humanacollabora: Collaboration tools - github.md at master - humanacollabora - SDF GIT Society

1 Like
2

I personally cannot do much of anything about the original build server, it’s a dedicated host running a Jenkins instance. I don’t know what happened, and even if I did I have limited capacity to fix anything about it.
My focus is the success of the project itself, that’s what I’m passionate about. In the very short term, this release is already very badly delayed, and shifting to anything other than github actions would have caused a much longer delay in the release. I’m using as much in the way of open source tools and services as possible because they’re better than the alternatives. Yes there is a very real concern about proprietary tools and infrastructure, and during the next release cycle I will be looking into alternatives, because the status quo just 6 months ago was robust build infrastructure on Jenkins, Travis, and GHA, and now it’s just GHA because the Jenkins host issue and because the Travis open source support program seems to be imploding.
Please note, this file is the extent of “vendor lockin” we have for github actions releases: Cataclysm-DDA/release.yml at 90f9945d362ce9e423fbc0c94c12ec13f2a66559 · CleverRaven/Cataclysm-DDA · GitHub
It’s not an elaborate interdependency thing, it’s merely a build script targeting the GHA environment.
I can probably crank out a gitlab or other system duplicate of this in about a week, but I don’t have that week right now.

If you want to marshall some information about what steps we can take to use more friendly/ethical/etc hosting, that would go a long way toward making it happen.

10 Likes
3

Hello. I thank you for you dedication to the success of CDDA and that you recognise this as a problem.

I’m afraid I cannot provide much input into replacements as I never set up CI myself. I did participate in a project that had a builder and as I remember, it was a Travis CI instance on a project-owned host. I was not involved in managing it.

The extent of vendor lock-in is not limited to that file. The real lock-in is formed by the user and development community around GitHub. In my experience, people and not the services, are always the hardest to move. But every bit of dependence makes the whole process harder.

I am fine if GHA is used, provided that there is a working alternative at standby. GitLab is somewhat of a grey area. GitLab.com is running GitLabEE, which is proprietary closed-source and thus I normally wouldn’t want to touch or recommend it. However, the basic (not really basic) service is free software (GitLab CE) that is self-hosted by many projects in addition to community instances across the internet.

I will look into ensuring that there is fallback.