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
  • [ ] Harden: https://github.com/docker/docker-bench-security
  • [ ] 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.