Cannot connect to VM when ran from launch agent

[olejnjak]

Hi guys, this would be more a question/consultation, more than an issue as I think you might have experience with this.

Since upgrading my machine to macOS Sequoia, running Gitlab Runner as launch agent (doesn't matter if gitlab-runner install/start or brew services start gitlab-runner is used) caused that Gitlab Tart Executor is never able to connect to running VM.

Running with gitlab-runner 17.3.1 (66269445)
  on Kuba-Macbook kniWxGMLU, system ID: s_2aed60cdbebf
  feature flags: FF_RESOLVE_FULL_TLS_CHAIN:true

Preparing the "custom" executor
Using Custom executor...
2024/09/20 01:56:13 Pulling the latest version of ghcr.io/cirruslabs/macos-sequoia-vanilla:15.0-rc...
2024/09/20 01:56:13 Cloning and configuring a new VM...
2024/09/20 01:56:13 Waiting for the VM to boot and be SSH-able...

In this state the job is stuck probably forever, I have lost patience after 10 minutes. On first run Gitlab Runner asks for permission to access local network, that probably makes sense, but it seems like it doesn't allow it to connect to the VM over SSH.

If I run gitlab-runner run directly from terminal, everything works fine. Would you have an idea how to fix this problem? I haven't found many info on launch agents permission changes in Sequoia so it is a bit tricky to fix.

Versions:

olejnjak@Jakub-Macbook ios-tart-images % gitlab-tart-executor --version
executor version 1.19.0-cbb18ff
olejnjak@Jakub-Macbook ios-tart-images % tart --version
2.18.2
olejnjak@Jakub-Macbook ios-tart-images % gitlab-runner --version            
Version:      17.4.0
Git revision: b92ee590
Git branch:   17-4-stable
GO version:   go1.23.1
Built:        2024-09-19T11:05:07+00:00
OS/Arch:      darwin/arm64

Not sure if Tart 2.18.3 would make any difference but it is not yet available through Homebrew.

This is how the launch agent looks like:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>EnvironmentVariables</key>
	<dict>
		<key>PATH</key>
		<string>/opt/homebrew/bin:/opt/homebrew/sbin:/usr/bin:/bin:/usr/sbin:/sbin</string>
	</dict>
	<key>KeepAlive</key>
	<true/>
	<key>Label</key>
	<string>homebrew.mxcl.gitlab-runner</string>
	<key>LegacyTimers</key>
	<true/>
	<key>LimitLoadToSessionType</key>
	<array>
		<string>Aqua</string>
		<string>Background</string>
		<string>LoginWindow</string>
		<string>StandardIO</string>
		<string>System</string>
	</array>
	<key>ProcessType</key>
	<string>Interactive</string>
	<key>ProgramArguments</key>
	<array>
		<string>/opt/homebrew/opt/gitlab-runner/bin/gitlab-runner</string>
		<string>run</string>
		<string>--syslog</string>
	</array>
	<key>RunAtLoad</key>
	<true/>
	<key>WorkingDirectory</key>
	<string>/Users/olejnjak</string>
</dict>
</plist>

Thanks for the help 🙏 🙂

[edigaryev]

Hello Jakub 👋

This is related to golang/go#68678, where Golang's linker does not emit a LC_UUID identifier critical for Apple's Transparency Consent and Control framework.

You can work around this by re-building GitLab Runner on your own:

git clone -b v17.4.0 https://gitlab.com/gitlab-org/gitlab-runner.git
cd gitlab-runner/
go build -ldflags="-linkmode=external" -o gitlab-runner main.go

Afterwards, update your job definition to use the new path to the gitlab-runner binary.

The permission box will pop-up again when starting the next job, but it should work this time because the binary now has an LC_UUID identifier.

[olejnjak]

Awesome, thanks for sharing, this is something I would never find out 🙄