Setup Issues for GitLab Runner on Mac Mini with M2 Processor

Encountering setup difficulties when trying to configure a pair of Apple Silicon-based Mac Minis as GitLab Runners. Here’s an overview and troubleshooting steps taken:

Initial Attempt at Setup

Followed the standard procedure for setting up runners, encountering issues with permissions not allowing logs files write access which caused a Failed to start gitlab-runner error (exit status 134). Steps included downloading and installing binary using curl. Despite these efforts, commands were unsuccessful when executed in /usr/local/bin.

Debugging Command Outputs

Running the GitLab runner with --debug, revealed a Runtime platform for arm64 on Darwin that suggested running sudo due to user-mode execution:

% /usrlaus local bin gitlab-runner --debug run ...  builds=0

This hinted at potential permission issues, which needed addressing.

Troubleshooting Steps and Solutions Taken

Upon further investigation into the log files’ permissions:

1. Permissions Adjustment: Changed directory of logs to a writable path (/Users/$USERNAME/.gitlab-runner) for both log and error outputs, ensuring proper file writing capabilities during runner operations.

2. Bootstrap Command Execution Local Terminal Issue Resolved by SSH Copying Steps: Realized local terminal commands were not identical to what was executed over ssh prompts due to different session handling in MacOS for apps launched via open versus command-line execution methods like cron or using .plist.

3. Configurations and Toml File Missing Section Fixes: Added the missing [[runners]] section from /etc/gitlab-runner/config.toml, copying it to personal configuration directory (~/.gitlab-runner). This aligns with GitLab’s recommended setup, as detailed in their documentation for MacOS arm64 configurations here.

After these troubleshooting steps and implementing the changes suggested by Docs:

• Stopped existing run with gitlab-runner stop.
• Reconfigured runner setup using new logs directory permissions, copying correct bootstrap commands via ssh (mimicking local terminal actions), and adding necessary sections to Toml config.

Result After Resolutions

Runner was successfully brought up again:

$ gitlab-runner start

status output indicates successful startup build=0 worker=1 runners[worker_id]=connected, visible in GitLab web interface under the Runners section for MacOS arm64.

Final Advice from Experts and Documentation:

Make sure to address permissions issues by ensuring log files are writable during setup; understand that local terminals on macOS might present different behaviors compared with ssh sessions, especially when copying bootstrap scripts or using system services like open. Always ensure the configuration file (config.toml) is properly set up according to GitLab’s official guidance for your specific platform and environment here.