"su: illegal option -- s" on OS X with shell executor and --user

When integrating with an OS X runner using the shell executor and the --user option, the build fails:

gitlab-ci-multi-runner 0.5.0 (c38415a)
Using Shell executor...
su: illegal option -- s
usage: su [-] [-flm] [login [args]]

ERROR: Build failed with: exit status 1

I've found this in the debug log:

command: su
arguments:
- --shell
- /bin/bash
- --login
- gitlab-runner

Looks like the su command is run with the --shell and --login options which aren't supported in OS X (see man su).

Currently OSX in that mode of operation is not supported. I'm happy to accept MR that will fix that.

Milestone changed to v0.7.0

Added ~58730 ~87609 labels

I'm very interested by this.

I've started looking at the code and seems that all this happens in shells/bash.go:131+.

I'm no Go ninja but happy to have a look and push a MR. Do you guys already have a set of tools to detect the current platform?

Could you point me to a code sample where its being used?

Thanks.

I just ran into the same problem whilst trying to get automatic builds working for an iOS project. Is there any known workaround yet?

Not that I'm aware of, at least not using this runner.

I'm still using the old runner (https://github.com/gitlabhq/gitlab-ci-runner) for my iOS projects and it works okay - but I'd also prefer a solution using this runner..

My solution is to have the gitlab-runner user run the daemon. That way, I don't need the --user parameter. The same user pulls the CI server and executes the builds.

Here's my /Library/LaunchDaemons/com.gitlab.gitlab-runner.plist configuration file:

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd" >
<plist version='1.0'>
<dict>
        <key>Label</key>
        <string>com.gitlab.gitlab-runner</string>
        <key>UserName</key>
        <string>gitlab-runner</string>
        <key>ProgramArguments</key>
        <array>
                <string>/usr/local/bin/gitlab-ci-multi-runner</string>
                <string>run</string>
                <string>--working-directory</string>
                <string>/Users/gitlab-runner</string>
        </array>
        <key>KeepAlive</key>
        <true/>
        <key>RunAtLoad</key>
        <true/>
        <key>SessionCreate</key>
        <true/>
        <key>Disabled</key>
        <false/>
</dict>
</plist>

Notice the UserName option. Also, I've renamed the service com.gitlab.gitlab-runner for better consistency.

Currently the installation as root is not supported.

The LaunchAgent is created when gitlab-ci-multi-runner install is executed as regular user.

The problem is Launch Agents are executed by the currently logged-in user. So you cannot use them to run services on a headless server.

Yes, I agree. Maybe you can propose fix for that?

Indeed, for the iOS simulator to be able to spawn up the process has to be launched from the LaunchAgents of the build user instead of the LaunchDaemons.

I'd be happy to have look into this with a bit of guidance. @ayufan do you have any leads on whats required and what to start with?

Currently I'm using the following LaunchAgent file to launch the previous runner:

<?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>Label</key>
  <string>com.gitlab.ci.runner</string>
  <key>EnvironmentVariables</key>
  <dict>
    <key>RBENV_VERSION</key>
    <string>2.0.0-p353</string>
  </dict>
  <key>ProgramArguments</key>
  <array>
    <string>/Users/gitlabci/.rbenv/shims/bundle</string>
    <string>exec</string>
    <string>bin/runner</string>
  </array>

  <key>WorkingDirectory</key>
  <string>/Users/gitlabci/gitlab-ci-runner</string>

  <key>SessionCreate</key>
  <true/>

  <key>RunAtLoad</key>
  <true/>

  <key>KeepAlive</key>
  <true/>
</dict>
</plist>

Cheers.

Milestone changed to v1.1

Milestone changed to v1.2

You guys just published a post [1] about using OS X for testing. You might want to reference this issue or update some of the info. I notice this bug says that installing as root is not supported in OS X but when you run as a user you get in bright yellow:

WARNING: Running in user-mode.
WARNING: The user-mode requires you to manually start builds processing:
WARNING: $ gitlab-runner run
WARNING: Use sudo for system-mode:
WARNING: $ sudo gitlab-runner...

Which would appear to imply that you should install it as root with sudo. At the very least if you can't fix this right away make SOME effort with having documentation be correct.

[1] https://about.gitlab.com/2016/03/10/setting-up-gitlab-ci-for-ios-projects/

@grzesiek @ayufan please also report back on the blog post https://about.gitlab.com/2016/03/10/setting-up-gitlab-ci-for-ios-projects/#comment-2583769695

@cardoe This message is a little misleading, sorry for that. I did improve that. You should be able to install GitLab Runner as user service with gitlab-runner install running as normal user, not a privileged one.

The problem that you are having according to this thread: https://stackoverflow.com/questions/27189296/homebrew-mxcl-mysql-plist-launchctl-load-error is:

The user running the command must be logged in via the GUI. Then, the command will work over both SSH and with a local terminal on the machine.

mentioned in merge request !114 (merged)

@cardoe You may be interested in testing that: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/merge_requests/119

mentioned in merge request !121 (merged)

Thanks @ayufan. The docs on launchctl appeared to imply user/UID should have worked but it did not until I was logged in through the GUI. I think this issue will be fixed with the v1.1 release based on the merge requests you've applied.

@cardoe The requirement for user to be logged in will stay. Otherwise you can't do UI interactions which are pretty common for builds on OSX. This is clearly documented in part describing OSX service.

Status changed to closed