CI: use GitLab instead of GitHub Actions

[strager]

Let's try GitLab's CI solution.

Benefits over GitHub Actions:

• Improved security for our macOS M1 worker
• Dedicated hardware for x86_64 Linux, macOS, and Windows workers, possibly improving performance
• FreeBSD integration (#761)
• Less dependence on proprietary software and services (#777)
• Better debugging; can reproduce CI issues locally
• Fewer surprises (GitHub breaks things occasionally)
• We can possibly sign builds in CI, simplifying releases
• Easy access to CI analytics

Downsides of GitLab CI:

• Weaker security and privacy overall because workers run in my home lab
• Higher maintenance
• Worse integration with GitHub for surfaces like pull requests

• [ ] Host GitLab or create GitLab.org account
• [ ] Runners & executors
  • [ ] Linux
  • [ ] macOS x86
  • [ ] macOS ARM
  • [ ] Windows
• [ ] Port ~~all~~ most jobs
• [ ] Integrate with GitHub

[vegerot]

https://about.gitlab.com/solutions/github/

[strager]

I did some research into this.

I set up a GitLab CE instance on a Debian 11 VM, then set up a docker runner on an Ubuntu 22.04 VM. It seems to work okay.

Plan for runners/executors:

• stracle (Windows x86)
  • Windows VirtualBox VM (provisioned with Vagrant) or Docker-Windows (unsure)
• strapurp (Linux x86)
  • Docker
  • FreeBSD VirtualBox VM (provisioned with Vagrant) (eventually)
• stracle (macOS ARM)
  • macOS Parallels VM
• straddler (macOS x86)
  • macOS Parallels VM or macOS VirtualBox VM (unsure)
• straglum (Linux x86)
  • Docker

[strager]

I got Docker-Windows working on my Windows machine. However, process isolation doesn't work. (Hyper-V isolation does work.) Implementing a firewall seems easier with process isolation, and I suspect performance is better too. Will do more research.

[strager]

MSVC Debug build times (cmake --build build --config Debug):

Host	Hypervisor	License cost	MSVC Debug build time
GitHub CI		0$	6m 59s
Windows (stradler)	VMware	0$ or 199$**	2m 57s
Windows (stradler)	VirtualBox	0$
Windows (stradler)	Hyper-V	0$
Windows (stradler)	Docker (Hyper-V)	0$	3m 1s
macOS (straddler)	Parallels	0$*	4m 40s
macOS (straddler)	VMware	0$*	5m 17s ~ 5m 45s
macOS (straddler)	VirtualBox	0$
Linux (straglum)	VMware	0$ or 199$**
Linux (straglum)	VirtualBox	0$
Linux (straglum)	qemu-kvm	0$

* Would be shared with macOS guests, so effectively free. 99$/yr (Parallels) or 199$ (VMware) if not shared. ** VMware Workstation Player is 0$ but has no snapshot support.

[strager]

Note: After installing VS, run c:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngen.exe executequeueditems. This saved 10 seconds for build times in Parallels.

[strager]

I got a GitLab Runner working with a Parallels VM. Some notes:

• Guest IP must be DHCP-assigned
• SSH username and identity file (and maybe blank password?) must be specified in runner config
• SSH disable_host_key_thingy must be specified in runner config (because DHCP assigns different IP addresses each run)
• I'm unsure if "isolation" mode must be turned off. I tested with it off.
• Had to apply this patch to work around prlctl exec vmname exit 0 always returning 2 (even if commands like prctl exec cmd /c 'exit 0' work):

diff --git a/executors/parallels/parallels.go b/executors/parallels/parallels.go
index 7acbdf8f9..52fd4eae7 100644
--- a/executors/parallels/parallels.go
+++ b/executors/parallels/parallels.go
@@ -136,11 +136,11 @@ func (s *executor) createVM(baseImage string) error {
 	// TODO: integration tests do fail on this due
 	// Unable to open new session in this virtual machine.
 	// Make sure the latest version of Parallels Tools is installed in this virtual machine and it has finished booting
-	s.Debugln("Waiting for VM to start...")
-	err = prl.TryExec(s.vmName, 120, "exit", "0")
-	if err != nil {
-		return err
-	}
+//	s.Debugln("Waiting for VM to start...")
+//	err = prl.TryExec(s.vmName, 120, "exit", "0")
+//	if err != nil {
+//		return err
+//	}
 
 	s.Debugln("Waiting for VM to become responsive...")
 	err = s.verifyMachine(s.vmName)
@@ -340,11 +340,11 @@ func (s *executor) ensureVMStarted() error {
 	// TODO: integration tests do fail on this due
 	// Unable to open new session in this virtual machine.
 	// Make sure the latest version of Parallels Tools is installed in this virtual machine and it has finished booting
-	err = s.updateGuestTime()
-	if err != nil {
-		s.Println("Could not sync with timeserver!")
-		return err
-	}
+//	err = s.updateGuestTime()
+//	if err != nil {
+//		s.Println("Could not sync with timeserver!")
+//		return err
+//	}
 
 	return nil
 }

[strager]

straddler perf notes: Parallels template VM takes about 20+4 seconds to boot. Snapshot VM takes about 9+3 seconds to boot. Git clone (LAN over WiFi) takes about 14 seconds.

[strager]

For GitHub integration: parts of the feature are available in CE, but some are not. The advertised GitHub integration is not free. However, @vegerot suggests that the relevant code might be open source but merely disabled by default.